The Honeymoon is Over, My Relationship with NHibernate

I have been using NHibernate for over a year now to help me develop 2DoNext.com. After all this time I have very mixed emotions about it. When I was first introduced to NHibernate I was really excited. It seemed to be able to handle the database tasks that as a programmer I don’t enjoy doing. Such as basic updating, selecting, and deleting. I quickly installed it and went through the tutorials, I talked to the programmer who introduced it too me and tried to get as much information as I could. It was like the first few weeks when you start dating that new girl, like heaven. It was a dream come true, I was in a wonderland thinking of all the great things that I could do with this wonderful technology.

As with all relationships slowly reality began to set in. Setting up NHibernate is not as easy as they would like you to think. Finding the “best” way to implement it in a web architecture was hard to say the least. Searching online I found more arguments than I did solutions. In the end I just had to pick the one I thought was best based on my knowledge of ASP.Net and the little I knew of NHibernate. It turns out that there was a few flaws in the implementation that I picked but I think I fixed them.

After the excitement reality sets in. The learning curve for NHibernate is really high. There are several things that are built into it which are not very easy to do because of the complexity of the architecture, such as using subclasses, joining multiple tables to create one class, and selecting items that are only have specific attributes.

What really makes her tick? One of the biggest problems that I have had with it is that I need to know what is going on in the database. Sometimes there are situations where I will need to get into the database and change something. Maybe delete a bad entry or a duplicate row. When I was first using NHibernate I was not comfortable doing this because I was not sure what it was really doing with all the index rows and such. I have since figured out what is going on in the database and realized that it isn’t easy to just delete a row in some cases.
As a quick example on my book rating site we have many collections, such as books you have rated, books you own, and books you recommend. If say in the books you own list somehow a book gets inserted twice. I would like to go to the database and just delete one. But with NHibernate it also stores the order the books go in the list. So you have to delete the row and update all records that have a order number higher than that row to shift them down one.

Well, this is getting long. So I will finish it up. By saying that I have read a lot of the arguments for and against NHibernate and personally I think that in the end I spent as much time trying to learn NHibernate as I would have if I just did the Data access work on my own. For me I am not planning on using NHibernate again because I spent and still spend too much time trying to figure out how to do something which I could easily do using a Stored Procedure and a Data Object.

So the honeymoon is over, we have realized that we are not compatible, and it is best that we go our separate ways.

Next time I will talk about what I use instead of NHibernate, because something has to be done about all that Update, Insert, and Delete code.