2
votes

I have created an IDbContext object that is provided to my IRepository implementations. The DbContext provides a way for my business logic to create, commit and rollback transactions and commits as needed. It also transports my NHibernate ISession, so my NHibernate implementation of IRepository can access it.

I am using this setup in a web application, where one DbContext is created per request and shared at by all repositories. At the end of the request, I dispose of the ISession.

Through your experience or knowledge of standard NHibernate practices, is it acceptable to have my DbContext flush and commit any outstanding transactions (provided there are no errors) automatically, when I'm disposing and about to close up my session?

2

2 Answers

1
votes

Yes, last time I checked at least, I believe this is the architecture used in S#arp Architecture. It also makes sense logically I think - if there hasn't been any errors, why would you not want to commit everything to the database?

1
votes

It's a common practice and is certainly acceptable, however it's not one I favor. I think it has a significant drawback in that the end of the request is too late to perform meaningful exception handling. I prefer to handle the transaction on the page so that I can catch exceptions and handle them there. In fact, I throw an exception in the EndRequest handler if the current ISession has an open transaction.