Benjamin Day Consulting, Inc.: The Blog

Continuing my rant about NHibernate being a whole lot of stuff to learn, it's also somewhat difficult to know how to actually do things the “right way”. 

A big one for me was trying to figure out the best way to manage NHibernate sessions from an ASP.NET application.  If you were doing a Windows Forms application with NHibernate, it would be pretty easy to manage the session.  You'd open the session and probably put it in a static variable somewhere. 

Well, that kinda doesn't really work out so well for an ASP.NET application because that static variable is a Singleton to the app domain so it'll be shared across all requests.  Sounds like a threading nightmare waiting to happen. 

Then there's the option of putting the NHibernate session into the ASP.NET Session.  That's stinky because it could be open for a really long time and there isn't really any bulletproof way to kill the NHibernate session if the ASP.NET Session gets abandoned or otherwise shut down. 

And then there's thread local storage blah blah blah that doesn't work out well either for some reason blah blah blah.

Whatever.  Bottom line.  There are a whole mess of options that stink and no real rock-solid consensus on the news groups about what to do.  There's some agreement that opening up an NHibernate session for every web request will work but it took some digging to find that.  There was some sample code but not a complete working example. 

So.  It's not fantastic but it's something.  I started writing a bug tracker sample application as a proof of concept using NHibernate.  http://www.benday.com/temp/BugTrackerNHibernateSample.zip  It has a ASP.NET user interface and a Windows Forms user interface.  I've included a backup of my “bugs“ database. 

The key thing to look at is the NHibernateHttpModule in Com.Benday.BugTracker.DataAccess and how it gets registered in web.config.  This module gets loaded and creates an NHibernate session that exists for the duration of the http web request.  I based this largely (translation: entirely) on Ed Courtenay's code that he posted at http://sourceforge.net/forum/message.php?msg_id=2847509.  I think it works pretty well. 

Feel free to critique the approach.  I know that what I'm doing with NHibernate probably isn't perfect.

-Ben

FYI, other posts on NHibernate are available here.

Ok.  So.  I've been playing with the object relational mapping framework called NHibernate for a while now. 

I'm pretty conflicted about it.  It's definitely cool and it has a lot of great features (most of them I'm probably not even aware of yet). 

If you're doing .NET development, it's pretty much a given that you know ADO.NET and probably 99.9% of .NET shops use ADO.NET.  Even if you're not a database expert, doing basic CRUD operation with ADO.NET is pretty easy and even if you don't know how to do it, there are 4000 books out there that'll teach it to you it in about 2 pages.        

And then there's NHibernate.  If your architecture goes heavy on business entities and light on DataSets, NHibernate solves your sticky data access problems.  You set up your O/R xml mappings and you're pretty much good to go.  Where it gets sticky is when you have to start doing custom queries against the db.  Example, give me all the users that aren't associated to the a customer who have been created in the last year.  NHibernate will do that for you.  The problem is that you've got to learn the NHibernate syntax and that syntax is definitely different.  If you know database programming, you’re going to get pretty frustrated trying to figure this out the first time you want to do it.

And that's where I start to see a big downside to NHibernate.  It's just another technology for someone to learn in order to get their work done. 

From a nerd's perspective:  It's cool.  It's nifty.  It's a new way to do stuff in .NET.  Hell...it might even let you write more elegant code.

From a company's perspective: It's just more stuff to worry about supporting.  You can't hire your average .NET programmer off the street because he/she very likely has never HEARD of NHibernate let alone actually worked with it enough to maintain a company's code base. 

The jury's still out.  [Update 12/10/2005: The jury came back in early October.  Here's the update.]

-Ben

 FYI, other posts on NHibernate are available here.