Exception — это мечта программиста, это возможность побыть Оракулом: «заглянуть в будущее» и написать код в стиле «если выполнении этого кода когда-нибудь отвалится, то поправить это так и так».
Отсюда простое правило — если возникла ошибка, и код сам знает, как ее поправить, то исключение генерить не надо.
>>Exception`ы более медленный механизм, чем «код возврата ошибки»
Верно, а php еще более медленный, чем exception в C++. Давайте не юзать php и исключения, что ли?
Exception на то и «исключительная ситуация», чтобы происходить достаточно редко. Так что на производительность она оказывает минимальное влияние. Убирайте #3 в разделе pro :) Хотелось бы увидеть аргументированные цифры, насколько именно «проседает» производительность при использовании исключений (обращу внимание — в нормальном режиме, а не в «беличьем колесе» while с бешеным количеством throws/сeк.)
Чего действительно не стоит делать, так это реализовывать программную логику на них: т.е. выбрасывать их не потому, что произошло что-то непредвиденное, а как нормальная реакция на одну из веток алгоритма.
Позвольте уточнить — из-за _явной_ транзакции на сохранении. Вы же не предполагаете, что может быть сохранение вне транзакции в БД? А падение производительности происходит из-за лишнего обращения к серверу БД по сети при обслуживании транзакции.
>> в HBM производительность из-за транзакции на сохранении падает в 10 раз.
Придется Вас огорчить :) С версии 2.0 в NHibernate автоматические транзакции были объявлены небезопасными: вы обязаны выполнять в явной транзакции даже чтение данных
>>Репозиторий – это фасад для доступа к базе данных (*)
Мне кажется, данная мысль не соответствует исходной посылке Фаулера. По его мнению, репозиторий — это то, что позволяет оперировать с объектами, соблюдая принцип «Persistence Ignorance», т.е. не задумываясь, есть там БД или нет. У вас же получаются врапперы (правда, более или менее сложные) которые просто изолируют приложение от Linq (и то, не всегда — когда речь заходит об extension methods, используется IQueryable. Конечно, можно сказать, что классы ваших репозиториев могут на самом деле и не работать с БД, но тогда вы будете противоречить сами себе (*).
В реальной практике редко (почти никогда) бывает возможно применить generic-репозитории, как это есть у вас; кроме того, модель CRUD превращается в кошмар, когда нужно работать не с раздельными объектами, а с их отношениями — в этом плане UnitOfWork куда удобнее.
Тем не менее, как пример реализации CRUD на linq, статья полезная, спасибо.
Отсюда простое правило — если возникла ошибка, и код сам знает, как ее поправить, то исключение генерить не надо.
>>Exception`ы более медленный механизм, чем «код возврата ошибки»
Верно, а php еще более медленный, чем exception в C++. Давайте не юзать php и исключения, что ли?
Exception на то и «исключительная ситуация», чтобы происходить достаточно редко. Так что на производительность она оказывает минимальное влияние.
Убирайте #3 в разделе pro :)Хотелось бы увидеть аргументированные цифры, насколько именно «проседает» производительность при использовании исключений (обращу внимание — в нормальном режиме, а не в «беличьем колесе» while с бешеным количеством throws/сeк.)Чего действительно не стоит делать, так это реализовывать программную логику на них: т.е. выбрасывать их не потому, что произошло что-то непредвиденное, а как нормальная реакция на одну из веток алгоритма.
Позвольте уточнить — из-за _явной_ транзакции на сохранении. Вы же не предполагаете, что может быть сохранение вне транзакции в БД? А падение производительности происходит из-за лишнего обращения к серверу БД по сети при обслуживании транзакции.
>> в HBM производительность из-за транзакции на сохранении падает в 10 раз.
Придется Вас огорчить :) С версии 2.0 в NHibernate автоматические транзакции были объявлены небезопасными: вы обязаны выполнять в явной транзакции даже чтение данных
Именно. Особенно тем разработчикам, которые могут внутри TransactionScope (http://habrahabr.ru/blogs/net/52173/#comment_1386154 делать раундтрип к БД на каждый Save для каждой Entity из некоторого набора =)
Мне кажется, данная мысль не соответствует исходной посылке Фаулера. По его мнению, репозиторий — это то, что позволяет оперировать с объектами, соблюдая принцип «Persistence Ignorance», т.е. не задумываясь, есть там БД или нет. У вас же получаются врапперы (правда, более или менее сложные) которые просто изолируют приложение от Linq (и то, не всегда — когда речь заходит об extension methods, используется IQueryable. Конечно, можно сказать, что классы ваших репозиториев могут на самом деле и не работать с БД, но тогда вы будете противоречить сами себе (*).
В реальной практике редко (почти никогда) бывает возможно применить generic-репозитории, как это есть у вас; кроме того, модель CRUD превращается в кошмар, когда нужно работать не с раздельными объектами, а с их отношениями — в этом плане UnitOfWork куда удобнее.
Тем не менее, как пример реализации CRUD на linq, статья полезная, спасибо.