As explained in various posts all over the internet (like this one at StackOverflow) the ISessionFactory interface is fundamental to how NHibernate works. As the StackOverflow links points out, creating a session factory is possibly the most expensive of the things NHibernate does during execution. A frequent misstep of developers new to NHibernate is to write code that will frequently – sometimes prior to each database call for the more heinous abusers – create session factory instances. As with any technology, that which isn’t used properly will probably result in less-than-favorable outcomes. NHQS simplifies this step for the developer, as well as facades the complexity associated with session factory storage once the application using the session factory has instantiated it.
Throughout this blog series the Visual Studio 2010 solution pictured to the left will be used. The solution consists of the NHQS framework, two domain projects, two data access projects to accommodate those domain projects, and a unit test project. To demonstrate how NHQS can connect not only to multiple database instances, but to multiple database platforms agnostically, the domain/data-access examples use 2 different databases; the People scenario will be backed by a SQL Server Compact Edition database and the Orders scenario will be backed by a SQL Server 2008 database. NHQS has support for many other database platforms so you should be covered in virtually all RDBMS situations.
Session Factory Creation via a Convention
Within NHQS there exists an interface named ISessionFactoryCreator. Obviously, that’s the spot at which our investigation will begin. The interface contract is shown below. The idea behind it is quite simple – just give a developer an easy way of handing their application a session factory and let them do pretty much whatever they want to do to create it.
The implementation of the session factory creator interface isn’t too difficult. For the People domain we’re using SQLCE, so the code below set up the session factory instance for that particular data source using the SQLCE persistence configuration and fluent auto-mapping. An in-depth exploration into these topics is beyond the scope of this post; I can assure you there are far better resources out there to explain such techniques. For now, take a look at the implementation.
Now that the session factory for the People data source can be created it’ll need a place to hang out in the application’s domain. The next aspect of NHQS, session factory containment, solves this problem for developers.
Session Factory Containment
One of the goals of NHQS is to provide multiple database access to a single application or web site. Inspired by the idea posited in the DAAB of “accessing multiple databases by name,” this goal was an interesting one to solve. As mentioned previously, the act of creating a session factory is an expensive one and must be done sparingly. Therefore, session factories can be thought of as things that you might want to make Singleton instances, so their storage is quite important.
Once a session factory is created it must be added to the session factory containment class. This isn’t too difficult and can be demonstrated in the unit test setup method below. When the application (in this case a unit test execution) starts up, all of the session factories used by the application should be created and added to the container.
The SessionFactoryContainer class does a little more than just contain the session factories created by each ISessionFactoryCreator implementation, too, but we’ll cover those in slightly more detail in the subsequent posts. For now, consider the multi-database goal alongside the domain centric access strategy goal. Since NHQS will be containing the session factories for you, chances are it will have the ability to do some mild interrogation of the entity domains it wraps.
Consider the code below, which modifies the test setup function slightly to accommodate a second session factory that is also created by an implementation of the ISessionFactoryCreator interface.
The next post in this series will begin to explain how, once the session factories have been created and contained, the domain-centric language can provide the CRUD operations necessary to work with the entities comprising these two domains. That’s when the power and simplicity of NHQS becomes obvious, so stay tuned!