>> Вы используете ТЗ (велосипед), я использую SRS (машину)
Вот здесь не понял :) На работе пользуемся SRS («specs», «спеки» на жаргоне), но ваша аналогия «велосипед» — «автомобиль» как-то неочевидна :/ Слово «велосипед» заставляет думать о ТЗ как о чем-то ненужном, лишнем, бесполезной трате ресурсов на поиск уже известного решения. Давайте назовем его «самокат»
Собстно, такой код, который вы привели, наглядно демонструирует, что при использовании исключений «мухи отдельно, коттлеты отдельно» — т.е. рабочий код чист и не загрязнен операциями зачистки/восстановления состояния после ошибок
Я бы не стал говорить про недостаток :) Иногда это превращается в достоинство — всегда известны тайминги операций (драйверы, low-level, nuclear facilities :)
Самая большая проблема исключений в том, что их генерация влечет за собой накладные расходы и операции, которые сами по себе могут быть источником проблем и исключений.
Простейший пример — нехватка памяти. Нужно выбросить exception, но не факт, что хватит памяти сконструировать сам экземпляр исключения. В управляемой среде (виртуальная машина java, интерпретатор php, или рантайм) сама среда берет на себя заботу об этом. В с++/MFC, например, чтобы памяти хватило, экземпляр исключения о нехватке памяти (и только такого) конструируется заранее, и затем везде выбрасывается один и тот же (вернее, указатель на один и тот же — чтобы исключить потенциально опасную операцию копирования объектов с контекста на контекст).
Насчет обертки — вы абсолютно правы, стоит делать как удобнее. Я только писал, что внутри DirectX продолжает оставаться COM-like, и не использует исключения — по указанным выше причинам.
Нет, я не про индусов :) я, в основном, про русских разработчиков в Той команде :)
Я бы использовал коды возврата в том случае, если это составляет логику работы программы. Ну и использовал бы их не в raw-формате, а как enum или его самописные аналоги (в Java)
P.S. Извините за медлительность, какой-то анонимус отметился в карму — видимо, не понравилось, что я слишком аргументированно спорил; и теперь ни писать в блог, ни комментить нормально не могу :( что с этим делать (плюсовать не надо, если вдруг, только ответьте)?
Вот так проявляется уникальная черта программистов — из неверных посылок делается верный вывод :)
Про выброс исключений и очистку ресурсов вы все правильно сказали, хотя посылка про неизвестность, критическая ошибка или нет, мне непонятна — про метод всегда известно, способен ли он сделать recover возникшей ошибки, или нет.
Собственно, сама возможность фильтровать по типу исключения внутри блока catch(SomeType ex) сделана для того, чтобы наглядно разделять recoverable и non-recoverable (извините за английский, он в данном случае выразительнее)
Таки позволю себе несогласиться :) Я застал то время, когда мы писали COM-объекты на Си. Так вот, как вы могли понять, не было исключений, и поэтому любой метод возвращал HRESULT, который должен был быть проверен (примерно так):
Ну и если вы посмотрите на исходники той же Windows (например, в Direct X, чтобы далеко не ходить), вы увидите, что они сами тоже не очень жалуют эксепшены, и в настоящее время продолжают писать в Cи/COM стиле. Так что рано еще хоронить коды возврата :)
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, статья полезная, спасибо.
Вот здесь не понял :) На работе пользуемся SRS («specs», «спеки» на жаргоне), но ваша аналогия «велосипед» — «автомобиль» как-то неочевидна :/ Слово «велосипед» заставляет думать о ТЗ как о чем-то ненужном, лишнем, бесполезной трате ресурсов на поиск уже известного решения.
Давайте назовем его «самокат»Статья полезная, спасибо.
Самая большая проблема исключений в том, что их генерация влечет за собой накладные расходы и операции, которые сами по себе могут быть источником проблем и исключений.
Простейший пример — нехватка памяти. Нужно выбросить exception, но не факт, что хватит памяти сконструировать сам экземпляр исключения. В управляемой среде (виртуальная машина java, интерпретатор php, или рантайм) сама среда берет на себя заботу об этом. В с++/MFC, например, чтобы памяти хватило, экземпляр исключения о нехватке памяти (и только такого) конструируется заранее, и затем везде выбрасывается один и тот же (вернее, указатель на один и тот же — чтобы исключить потенциально опасную операцию копирования объектов с контекста на контекст).
Насчет обертки — вы абсолютно правы, стоит делать как удобнее. Я только писал, что внутри DirectX продолжает оставаться COM-like, и не использует исключения — по указанным выше причинам.
Я бы использовал коды возврата в том случае, если это составляет логику работы программы. Ну и использовал бы их не в raw-формате, а как enum или его самописные аналоги (в Java)
P.S. Извините за медлительность, какой-то анонимус отметился в карму — видимо, не понравилось, что я слишком аргументированно спорил; и теперь ни писать в блог, ни комментить нормально не могу :( что с этим делать (плюсовать не надо, если вдруг, только ответьте)?
Про выброс исключений и очистку ресурсов вы все правильно сказали, хотя посылка про неизвестность, критическая ошибка или нет, мне непонятна — про метод всегда известно, способен ли он сделать recover возникшей ошибки, или нет.
Собственно, сама возможность фильтровать по типу исключения внутри блока catch(SomeType ex) сделана для того, чтобы наглядно разделять recoverable и non-recoverable (извините за английский, он в данном случае выразительнее)
Таки позволю себе несогласиться :) Я застал то время, когда мы писали COM-объекты на Си. Так вот, как вы могли понять, не было исключений, и поэтому любой метод возвращал HRESULT, который должен был быть проверен (примерно так):
if(FAILED(hr = _SomeFunction())){
… handling error…
}
Ну и если вы посмотрите на исходники той же Windows (например, в Direct X, чтобы далеко не ходить), вы увидите, что они сами тоже не очень жалуют эксепшены, и в настоящее время продолжают писать в Cи/COM стиле. Так что рано еще хоронить коды возврата :)
Пошел ставить новую фразу на screensaver :) просто и очень сильно сказано
Отсюда простое правило — если возникла ошибка, и код сам знает, как ее поправить, то исключение генерить не надо.
>>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, статья полезная, спасибо.