NHQS Part 3: Session Fluency Extensions

Though this might be the poorliest-named aspect of NHQS it is my favorite part, for it takes a huge part of the complexities associated with NHibernate and makes them simple. Dirt simple. Like, “you’re kidding, right? That couldn’t possibly work,” simple.

In part 2, the session factory containment methodology was discussed and demonstrated. During the stage of session factory containment NHQS does a wee little trick; it associates all of the domain (or if you prefer, entity) types with the session factory responsible for performing that domain type’s CRUD responsibilities.

What? Huh?

In other words, during containment, NHQS learns that, when asked for a Person, to hand back session factory A. When asked for an Order hand back session factory B. Whatever domain is requested, the framework should know which session factory to ask for that domain object; it should be transparent to the developer using NHQS.

Take a look again at the test fixture setup for the NHQS demonstration tests. This setup function was introduced in the previous post but has been augmented to help explain the topic in this post. The relevant addition has been highlighted for simplicity.


To further explain what’s going on, let’s walk through that highlighted section, piece by piece, and get a good understanding the steps taking place at execution time.


This first part looks in the session factory container and finds the session factory that has been set to perform CRUD operations against the SQLCE database that stores Person class instances. The return of the For<T> method is, obviously, the instance of the ISessionFactory interface that was previously stored in the container. Note – this isn’t creating a new session factory each time,because, as pointed out in a previous post, that’s the probably single most expensive [RE: painful] thing you can do with NHibernate. Since each session factory is created once and maintained within the session factory container, the container is just handing it back based on the type of domain object needed by the calling code.


Since the For<T> method hands back a session factory instance, this line should be relatively self-explanatory – it creates an NHibernate ISession instance and hands it back to the calling code. Now for the good stuff, the session extension methods.


Hanging off of the session object are a few NHQS extension methods. Located within the root NHQS namespace, these methods do pretty much what their normal method equivalents do – the CRUD operations against the database. The Save<T> method takes an instance of the domain object type represented in the generic argument and saves it to the NHibernate session and eventually, the SQLCE database.

Moving on, we need to have a unit test to make sure we stored some data. As with the Save<T> extension method, NHQS provides a retrieval methodology that uses LINQ Expressions to get to the data in the database.


This test will, obviously, pass, as the setup routine saved some data to the database. We can also ask for the specific data we saved to make sure the test isn’t returning other data that’s been persisted at some other time. The second unit test below demonstrates this in action.


Most of the extension methods have overloaded options, too, if you want to continue to chain together operations in a fluent manner. The test below demonstrates an example of this approach in action.


Just take a look at all the work NHibernate’s doing under the hood from the debugging log generated at run-time when this unit test (and the setup) are executed. As you’ll see, NHQS makes CRUD activities a lot simpler than doing multiple methods of database logic. Obviously, it makes such processes a little more testable, too.

Click to zoom

This post sums up probably the biggest benefit NHQS could provide most developers – easy, fluent access to their domain persistence via simple, domain-centric language and chainable methods.

The final post in this series (which may be split into two posts) will demonstrate two more important facets of NHQS – multiple-database access and the big kahuna topic in most database/ORM discussions – transaction management. We’ll peek at these two topics in the next few days and wrap up this NHQS introduction.

I hope you’ve enjoyed the series so far!