The accepted standard (until recently) would be to have some intermediate data access layer that would populate each field of an object with the column of data in a table. It would also take care of populating any associations of the object by querying the database on that object’s key, and populating the list. All of this would require a lot of scaffolding code to be written, as well as stored procedures, to store and retrieve this data, resulting in a lot more development time. This practice is also heavily error-prone, as stored procedures are not compiled code and are highly prone to errors. On top of that, adding say, a new field, would require the field to be added to the table, then to the stored procedure (or many stored procedures – usually 1 per CRUD operation!), then to the object, then to the scaffolding code that populates the object data.

Sounds like a nightmare? It is. That’s where object-relational modelling (ORM) frameworks come to the rescue. They attempt to bridge the gap between the object domain and relational data world by “hiding” a lot of the work that needs to be done in order to persist an object domain model to a relational database. One of these (and one of the most popular) is NHibernate. Originally it was written for Java but has since been ported to be used with .NET and has grown in features and popularity. It is also open source, which means it can be used without having to pay any licensing fees.

The basic steps required to use an ORM like NHibernate are: design and code your domain model, write a set of “mapping” files to tell NHibernate how your objects are mapped to the tables in the database, and that is pretty much it! The framework contains many functions to allow the storage and retrieval of the object data without having to write a single stored procedure or SQL query. It does this by generating the required SQL on-the-fly in the background, and it does quite efficiently as well. And don’t worry – it uses parameterised queries, so the code is not susceptible to SQL injection attacks.

If this sounds like a dream come true, well, it pretty much is. Don’t get me wrong – it has its own pitfalls, but generally, the time taken to get a basic data access layer up and running is pretty much halved. One of the most time-consuming tasks in this process is writing the mappings between the ORM and the database (usually a set of XML files), but this has also been alleviated via the introduction of Fluent NHibernate, which is a fluent extension of the mapping system. It allows type-safe compiled mapping to be written into the data access layer itself, and also includes a set of unit test extensions that can be used in units tests to ensure that the domain is correctly mapped to the database. “Fluent” relies heavily on lambda expressions for the mappings (introduced in .NET 3.0), so knowledge of these are essential. They’ve been around a while now, so if you’re not up with them, well, you better get cracking or you’ll be left behind!

More information about NHibernate and Fluent (and many other NHibernate libraries and extensions) can be found here: http://nhforge.org