NHibernate, Part 1 (of X)

It’s about time for the first technology related post. 

Since .NET came out, I’ve been a big fan of having a data access tier that fills and returns typed datasets using stored procedures .  It’s worked out well.  Easy enough to write and maintain.  It gives you a nice layer of abstraction off of the physical data store so you can re-arrange calls to the db, it’s good for managing transactions, and there’s a minimum of SQL in the code.  Nothing particularly exotic about it.

Then sometime last summer my friend Mike Miller came off a project doing a mix of .NET and Java.  Started talking about this Object Relational Mapping (ORM) framework called Hibernate and how he’d been checking out its .NET port, NHibernate.  “Blah, blah, blah, it’s awesome blah blah blah you don’t have to write data access code any more etc etc etc.“ 

Needless to say, I wasn’t sold.  

#1. I didn’t really mind writing data access code.   In the grand list of complaints, writing data access code wasn’t one of them.  I was skeptical that there would actually be noticable productivity gains.

#2. Most of my clients have legacy databases that they want to integrate with.  NHibernate sounded to me like it really wanted you to design your database for its needs.  Would NHibernate “play nice“ with that 10 year old, mission-critical database that maybe had a clean design originally but after years of maintenance is all logical scar tissue and band-aids?  Not bloody likely.

No more stored procs?  No more datasets?  Heresy.

A number of months went by and I didn’t do much (read: anything) with NHibernate.  In early December, I started seriously looking at it.  Now see that primarily I was hung up on the word “hibernate“.  It doesn’t mean anything like “hibernate“ in Windows.  After getting past that, it starts to look better.

It’s really different.

Business entity classes are mapped using XML to tables and fields in the database.  Relationships are defined between entities in the XML so that NHiberrnate automatically populates related classes when you load.  Once you get the hang of the XML syntax, this makes retrieval and population of data insanely easy.  The coolest thing is that once you have the mappings done for retrieve, you’ve got the saves all done as well. 

Here’s a sample mapping file for a bug tracking application I’m writing as an NHibernate proof of concept:

<hibernate-mapping xmlns=”urn:nhibernate-mapping-2.0″><br /> <class name=”Com.Benday.BugTracker.Business.Issue, Com.Benday.BugTracker.Business” table=”Issue”><br /> <id name=”IssueId” column=”IssueId” type=”System.Guid” unsaved-value=”00000000-0000-0000-0000-000000000000″><br /> <generator class=”guid” /><br /> </id><br /> <timestamp name=”LastModified” column=”lastModified” /><br /> <property name=”Title” column=”title” /><br /> <property name=”Description” column=”description” /><br /> <property name=”IssueType” column=”issueType” /><br /> <property name=”ProjectId” column=”projectId” /><br /> <property name=”IssueLocation” column=”issueLocation” /><br /> <property name=”Status” column=”status” /><br /> <property name=”Priority” column=”priority” /></p> <p> <property name=”CreateDate” column=”createDate” /><br /> <many-to-one name=”LastModifiedBy” column=”userId” class=”Com.Benday.BugTracker.Business.User, Com.Benday.BugTracker.Business” /> </p> <p> <bag name=”Actions” inverse=”true” cascade=”save-update” table=”IssueAction” order-by=”createDate”><br /> <key column=”issueId” /><br /> <one-to-many<br /> class=”Com.Benday.BugTracker.Business.IssueAction, Com.Benday.BugTracker.Business” /><br /> </bag><br /> </class><br /> </hibernate-mapping><br />

So.  To answer my initial questions….

Does it save you time by not having to write data access code?  Definitely. 

Will it integrate with that old legacy database?  I’m still a little skeptical on that one but so far it’s looking far better than I imagined. 

More to come on NHibernate.

-Ben

FYI, other posts on NHibernate are available here.