NHibernate is one of the most useful and complicated open-source projects in the .NET community. Some consider NHibernate prohibitively difficult. It can be quite difficult and frustrating, especially when you only want to use it to build a simple, prototype, or startup-size web site. That's where NHQS fits in.
This evening I was finally able to get the NHQS library up on NuGet. As always, you can use either the NuGet package explorer or the command-line tool to grab yourself NHQS.
Most of the previous posts have alluded to the multiple-database goal of NHQS and some of the code has demonstrated the beginnings of a demonstration of the feature. This post will take a longer look at how NHQS can provide multiple-database support and will wrap up by demonstrating transaction management within NHQS.
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.
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.
If you’ve worked with me over the past year or you’ve seen one of my alt group meetings, chances are I’ve mentioned, demonstrated, or maybe stuffed down your throat, the NHQS thingamabob. With the improvements in NHibernate following .NET 4.0 and the experiences I learned in a few projects in the previous release I’ve decided to rewrite NHQS for NHibernate 3.xx. I like the improvements in NHibernate and with those and a slightly renewed focus on my goal for NHQS I felt it might be worthwhile to introduce it on its own into the wild. This post will introduce the world to NHQS and provide a guideline for its usage.
As I mentioned in a previous post, Jim referred to on Twitter and officially named it, we’ve been tinkering with the idea of using Powershell and NHibernate together to move entity instances between persistence mechanisms. I’m going to cover how one can accomplish this functionality using Domain Console in this post. If you prefer just looking at PS1 files, a code download is available at the end of the post.
Inspired by my buddy Jim’s article series on the topic of creating Powershell drives, I had lunch with him to find out more about the complexities in doing so. Inspired by my Enterprise Library-like wrapper around NHiberate, he wanted to discuss with me an idea he had for a new drive provider that would universally access databases. The more we talked (and drank margaritas) the more the idea percolated as one with merit.
With Jim’s excellent article series as a starting point I created such a drive around “the knocks,” an NHibernate Quick Start library I created (that may be discussed later in more detail). The result appears to be something I think could be quite nifty – a command-line provider interface for any database platform supported by NHibernate.
Here’s a preview. The following cmdlet does a few things, which will be highlighted below. Imagine this as script you’d enter at a Powershell command line.
When this script is executed and the database-creation process executes, the SQL is shown to demonstrate the mapping has succeeded.
Then, due to NHibernate’s convenient logging features, you’ll see more SQL output in the console window reflecting the inserts and selects being performed against the SQLite database. This gives a glimpse into how the data is added to the database.
Lastly, a shot of just when the Get-Item part of the script is called.
Once the database has been wrapped, the final call can be made, to Get-Item.
The output of this results with the objects our debug-time database-saving had completed so test data would exist. When the output streams into the console it’s obvious – we’re querying a database-agnostic NH repository library directly using LINQ at the Powershell command line.
The first shot is of the SQL getting executed directly into the SQLite database via NHibernate.
The second is how the objects look – and how they can be interacted with – at the Powershell command line. They’re instances, object-relationally mapped directly from a database, fresh for copying (or migrating and then copying) into an RDMBS living somewhere completely different.
Hopefully we’ll have some more information on this coming up and a lot more refinement. For now though, would you think universal RDBMS access via object-specification and retrieval via generic selection would be useful?
I’ve been using [hacking at] NHibernate as my main ORM choice for just over a year and I’ve been exceptionally happy with the growing number of projects to augment it’s functionality, especially the Fluent NHibernate and LINQ-to-NHibernate contributions. NH isn’t exactly a simple ORM layer and does have some confusing aspects. One of these aspects – at least for me – has been that I’ve seen inconsistent behavior in the persistence of child collection properties. I think I concluded via a series of unit tests this evening for myself how to gain the typical desired outcome and I felt it was something I should share.