NHibernate ISession и автоматическая очистка / фиксация транзакций в моей единице работы

Я создал объект IDbContext, который предоставляется моим реализациям IRepository. DbContext позволяет моей бизнес-логике создавать, фиксировать и откатывать транзакции и фиксировать их по мере необходимости. Он также переносит мой NHibernate ISession, поэтому моя реализация NHibernate IRepository может получить к нему доступ.

Я использую эту настройку в веб-приложении, где для каждого запроса создается один DbContext, который используется всеми репозиториями. В конце запроса я избавляюсь от ISession.

Благодаря вашему опыту или знанию стандартных практик NHibernate, допустимо ли, чтобы мой DbContext очищался и фиксировал любые невыполненные транзакции (при условии отсутствия ошибок) автоматически, когда я утилизирую и собираюсь закрыть свой сеанс?


person moribvndvs    schedule 28.06.2010    source источник


Ответы (2)


Да, в последний раз я по крайней мере проверял, я считаю, что это архитектура, используемая в S # arp Architecture. Я думаю, это тоже логично - если ошибок не было, почему бы вам не зафиксировать все в базе данных?

person cbp    schedule 29.06.2010
comment
Да, сначала это кажется довольно простым, но, как заметил Джейми Айдл, это может быть довольно поздно в игре, чтобы разумно обработать ошибку. Я думаю, что лучший ответ (для моих конкретных целей) заключается в сбрасывании и фиксации открытых транзакций, но следуя строгой схеме, когда ошибки в явных транзакциях обнаруживаются, транзакция откатывается, а ошибка обрабатывается иным образом. - person moribvndvs; 29.06.2010

Это обычная практика и, безусловно, приемлема, но я не одобряю ее. Я думаю, что у него есть существенный недостаток, заключающийся в том, что конец запроса слишком поздно для выполнения значимой обработки исключений. Я предпочитаю обрабатывать транзакцию на странице, чтобы я мог перехватывать исключения и обрабатывать их там. Фактически, я генерирую исключение в обработчике EndRequest, если текущий ISession имеет открытую транзакцию.

person Jamie Ide    schedule 29.06.2010
comment
Есть один сценарий, в котором я вижу ценность в том, чтобы позволить DbContext управлять затяжной транзакцией в конце, и здесь ряд различных компонентов работает с сеансом и текущей транзакцией (у нас всегда будет хотя бы одна транзакция) для выполнения одной. после другого. Например, уровень безопасности может проверять роли, затем механизм настройки загружает личные настройки, затем основная часть запроса обслуживается, и, наконец, любой аудит записывается. Однако я понимаю вашу точку зрения и предпочел бы, чтобы мы обрабатывали явные транзакции, э-э ... явно. - person moribvndvs; 29.06.2010