The Freak Parade

Why?
For the past several years we have been using a home grown ORM tool as part of a larger application framework. It works pretty well, but there are a few drawbacks:

• It’s home grown – unless we divert attention from building our business applications, it stays frozen in time. This is a drawback of every home grown tool, and why a community or third party library should always be considered when good ones are available.
• It’s tied to SQL Server. Getting it to run on another database platform would be quite a bit of work.
• No LINQ support, in fact, no query language of any kind. When we want custom queries, we put them in our model editor and generate new code. This get’s us a method on our DAL to execute the query, but that means there is this whole open-model-editor, make change, generate code, compile code and test cycle for every little query we may need.
• As an internal tool, it is rather poorly documented. Training new developers requires using in-house staff. No pointing to a list of links on the web and saying, “here, go learn this and we’ll get started”
• It means nothing when you put it on a resume

As we are embarking on a new set of projects, the time seems right to consider the possibility of moving to a mainstream ORM tool with a healthy community and plenty of learning material. I won’t go through the selection process, but we looked at some commercial tools and we looked at NHibernate, and while the commercial tools have some nice polish on them and comprehensive documentation, the community surrounding NHibernate is so vibrant (and so distinguished) that we’re strongly leaning in that direction.

NHibernate does lack some polish. It’s an engine that requires some build-out of infrastructure to make it comfortable to use, but much of that build out has been contributed by community members and where it hasn’t, the blogosphere has filled the gaps with any number of helpful walk-through’s and best practices posts. I’ll post links to the resources I’ve identified in a subsequent post.

Active Record
Perhaps the most prominent of these community contributed build-outs is the oh-so-famous ActiveRecord implementation that is part of the Castle Project. NHibernate, in its raw, unprocessed form, handles persisting Plain Old CLR Objects (POCO’s) to a persistence medium by way of XML mapping files which must be hand crafted. The mapping file contains which fields of a persistent object will be stored to the database, and can control every detail of the mapping between a field and a corresponding database column. The mappings also communicate to NHibernate how entities relate to one another, such as many-to-one, many-to-many, etc.

All this is very powerful, but perhaps not so much fun to manage (although many people prefer to do so manually). Active Record is a design pattern for object relational mapping that maintains one Class for each Table in a data store, more or less, and Castle Windsor provides an implementation of this pattern such that a combination of Convention over Configuration and .NET Attributes remove the need for creating and maintaining NHibernate mapping files. In fact, when you use Castle’s ActiveRecord, you may not know you’re using NHibernate at all as the whole experience is nicely abstracted. To make this happen it is understood when you use Active Record your objects will be saved to the database in a certain way, and you are OK with that, because it saves you many small decisions and many XML code edits.

Whether or not to use ActiveRecord is, I think, largely a matter of taste and your personal relationship with Convenience(Cost) vs Control, the yin and yang of the Build vs Buy decision. We haven’t settled on ActiveRecord yet, although we are pretty sure that if we don’t use ActiveRecord, we’ll be rolling our own code generator to maintain both NHibernate Mapping Files and the Database Schema, and possibly the Entity classes themselves, based on a metadata model. Maintaining a few trillion XML mapping files doesn’t sound like a lot of fun to me.

Next I’ll talk a little about architecture, and then drown you in NHibernate hyperlinks.