So, I'm half way through the week and had a chance to reflect on all the information I absorbed at the UK Alt.net conference last weekend. There were 4 sessions I attended during the day and the 3^rd session was titled “NHibernate, Linq and ORM”. Out of all the sessions I attended, this was probably the largest. The majority of attendees of this session were NHibernate advocates. For me, when it comes to NHibernate the jury is still out, the following article describes one of the reasons why.

Some Background

Just to give you some background, I have been using NHibernate in-depth on a project for the last 9 months. I am no expert in the field but no novice either. Before using and ORM tool, I would write stored procedures in order to access crud functions of the database. Actually, “writing stored procedures” is overstretching, I would use codegen tools, run them over the database and plug my code into the resulting assembly.  This was cool for a number of reasons, firstly the output assembly would show any changes or conflicts in code at compile time, and secondly it defined an explicit contract with my data store. I’m big on scaffolding in code (I know its not 100% TDD) but it provides a great way to visualise your overall code architecture. 

When I started working on the project, I had very little exposure to ORM tools. I had read blog posts & articles but had never really cut my teeth on the technology. I would say that in the .net world, NHibernate is probably the no 1 ORM tool available. NHibernate is a port of the java implementation Hibernate which has been popular for many years. 

The thinking behind ORM tools is that they “become the database” and that you really don’t need to waste time writing SQL anymore. I have to say, the moment I started reading about ORM tools I felt a little uneasy. SQL is a language I am very comfortable with, more to the point it has been specifically developed in order to query data in a mathematical and consistent way. The idea of not touching SQL and focusing purely in code seemed a little frightening to me.  Trying to put my fears aside, I joined the project and jumped two feet into NHibernate.

The Learning Curve

In this model we have all objects connected in a parent-child fashion. In this case the selected class which does not have a related database table, controls access into our complex system.  This posed a bit of an issue for me as Nhibernate infers saving via a mapping file and in this case the selected class does not exist in the parent mapping file. Therefore, I felt I had run into an Object/Relational Impedance mismatch. Again, it was just my understanding of NHibernate, I soon found that I could solve this problem using NHibernate Components. So as you can tell, NHibernate is a large beast and it issues such as these that can really throw a spanner in your productivity. But they are not issues that cannot be resolved. 

NHibernate’s inherent Tight coupling

As my confidence with NHibernate has grown, I have felt that most issues can be resolved, all you need is the knowledge. However, there is one issue that I feel NHibernate creates that cannot be resolved. As I mentioned previously, I used to use stored procedures to interact with my database. Stored procedures in my mind are great as they enforce a contract between application code and the database.

Recently however, I hear people at conferences make snide remarks about them, like they are some form of pollution in the their code. I find this reaction strange, everywhere else in our code we spend time make sure there are adequate layers in order to reduce complexity and shield us from breaking changes.  So why is it that I hear people turning their nose up at sprocs? The answer lies in the history of sprocs, I think many of us have experienced sprocs that may be 100’s or 1000’s of lines of code. These procedures are in essence business logic, it’s this bad habit that has forced us to abandon them. A decision I feel is incorrect. 

What stored procedures really are are “service contracts”, regardless of bad practices implemented by devs or dba's in the past, they still serve a purpose in that they decouple the database schema from our application code. Its this important fact that I believe NHibernate misses and as a result leads to tight coupling between application code and the database schema. (Please note: I know NHibernate can use stored procs instead but I question the value NHibernate offers over codegen in the same situation).   

Lets take a simple mapping file for an address entity (shown below)

We could look to resolve this issue by implementing our mapping file so that it points to a view rather than the table, this however will only go so far, updates and deletes may need to span many tables which will be impossible to implement via view.  

So what do we do?

The answer is not clear, NHibernate & other ORM tools rely on mapping properties to database columns. This pattern results in tight coupling that makes applications suffer from a poor resistance to change.  We as developers cannot assume that the database is just for the application we are developing, data is a commodity and therefore commonly shared amongst multiple services, and the querying of that data may be good for one scenario but not the other.

Its seems ORM’s fall right into this hole, they offer us productivty but at a cost. As I said, the jury is still out for me as to whether the pro's out weight the cons but being aware is vitally important. 

I have a number of other issues I have comne across since using ORM's and I will be looking to blog about these in the future.