StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I have not used Spring.NET so I can't comment on that. However, the rest sounds remarkably (or perhaps not so remarkably; we're hardly the first to implement these things ;) similar to my own experience. I too had trouble finding a One True Best Practice so I just read as much as I could and came up with my own interpretation. </p> <p>In my situation I wanted transaction/session management to be external to the repository as well as keep repository concerns from bubbling up out of them (i.e. the code using the repository should not need to know that it's using NHibernate internally and shouldn't need to know anything about NHibernate session management). In my case it was decided that transactions would be created by default lest developers forget them, so I had to have a read-only escape mechanism. I went with the Unit of Work pattern with the NHibernate ISession instance store inside. Calling code (I also created a DSL interface for the UoW) might look something like:</p> <pre><code>using (var uow = UoW.Start().ReadOnly().WithHttpContext() .InNewScope().WithScopeContext(ScopeContextProvider.For<CRMModel>()) { // Repository access } </code></pre> <p>In practice, that could be as short as <code>UoW.Start()</code> depending on how much context is already available. The <code>HttpContext</code> part refers to the storage location for the UoW which is, unsurprisingly, the <code>HttpContext</code> in this case. As you mentioned, for a ASP .NET application, <code>HttpContext</code> is the safest place to store things. <code>ScopeContextProvider</code> basically makes sure the right data context is provided for the UoW (ISession instance to the appropriate database/server, other settings). The "ScopeContext" concept also makes it easy to insert a "test" scope context.</p> <p>Going this route makes the repositories explicitly dependent on the UoW interface. Actually, you might be able to abstract it some but I'm not sure I see the benefit. What I mean is, each repository method retrieves the current UoW instance and then pulls out the ISession object (or simply a SqlConnection for those methods that don't use NHibernate) to run the NHibernate query/operation. This works for me though because it also seems like the ideal time to make sure that the current UoW is not read-only for methods that might need to run CRUD.</p> <p>Overall, I think this is one approach that solves all your points:</p> <ul> <li>Allows session management to be external to the repository</li> <li>ISession context can be mocked or pointed at a context provider for a test environment</li> <li>Avoids unnecessary transactions (well, you'd have to invert what I did and have a <code>.Transactional()</code> call or something)</li> <li>I can't see why you couldn't test with SQLite since that's more of an NHibernate concern</li> <li>I use Fluent NHibernate myself</li> <li>Allows the repository to be ignorant of the host environment (that is, the repository caller controls the UoW storage context)</li> </ul> <p>As for the UoW implementation, I'm partially kicking myself for not looking around more before I started. There's a project called <a href="http://github.com/machine/machine.uow" rel="nofollow noreferrer">machine.uow</a> which I understand is fairly popular and works well with NHibernate. I haven't played with it much so I can't say if it solves all my requirements as neatly as the one I wrote myself, but it might have saved development time as well.</p> <p>Perhaps we'll get some comments as to where I went wrong or how to improve things, but I hope this is at least helpful in some way. </p> <p>For reference, the software stack I'm using is:</p> <ul> <li>ASP.NET MVC</li> <li>Fluent NHibernate on top of NHibernate</li> <li>Ninject for dependency injection</li> </ul>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload