I have always thought of some aspects in Software Development which makes it different from other industries. One of them is free and open source frameworks. Many software developers spend hours and hours creating frameworks and make it publicly available for other developers to use. They are soon joined by other enthusiastic developers and this lends to building awesome tools and frameworks that can compete with their paid alternatives.

Using frameworks can reduce development effort and allows developers spend more time on solving the real problems or help the business and avoid re-inventing the wheel. However, before using any framework you should consider a few points and ask yourself these questions.

  • Why are we using this framework? What problem are we trying to solve?
  • Do we know how to use it? How many of the developers in the team know how to use it or are bright enough to pick it up as quickly?
  • Is there any other similar framework that does the same job? What are the pros and cons?
  • And the most important one: are we brave enough to admit our mistake if we fail using a framework?

A few years ago I heard about NHibernate from my fellow developer who had been using Hibernate in Java and recommended it to us. We started using NHibernate some time later after convincing our managers that it was a good choice. It was great, no more SqlConnection and SqlAdapter, no more TypedDataSet (yes, we were using DataSet and DataTable, etc). Here we come NHibernate, OOP.

First mistake rose up while we were developing third project using NHibernate. In one part of the solution we had to save a considerable number of objects in one round. The operation would take a long time so the user would face ‘time out’ exception. Some started blaming NHibernate saying that it does not perform well, although it is clearly said in a lot of sources that NHibernate is not a good choice for batch operation. It could of course be tuned for a better performance (changing batch size, etc) but we solved that problem using another approach.

Recently, I have seen a couple of ridiculous errors using NHibernate that killed the performance of the applications and caused some saying the famous sentence, “NHibernate is sh**”, without thinking for a moment that if the problem is NHibernate or the developers.

In first pages of any book written about NHibernate, it is pointed out that SessionFactory must be created once for throughout the application, unless you have to connect to different databases where you need to create a different SessionFactory for each. The point is that you should not, in any circumstances, create a SessionFactory every time you need to carry out a database operation! Yes, you are right, someone had done this mistake. The result is that NHibernate has to do all the behind-the-scene warming-up operations over and over which makes the whole application terribly slow.

What NHibernate as an ORM does is to map your domain model objects to your relational database. To my opinion, it is the best available option for someone who knows OOP and wants to avoid writing SQL queries and avoid spending too much time on data access layer. The issue is that the design task is given to an inexperienced developer and the make stuff up. They define a class called Truck and add whatever they have in mind as many-to-one relation to Truck, e.g. EngineType, SeatType, LightType, … , and there are 20 of these. Whatttttttt? Whoever has had any exposure to proper-designed solutions can see big problems here:

  • No abstraction for the main class in the domain model. Truck!
  • Adding a new attribute to the truck needs some development time and changes to the entire solution.
  • And the most freaky one is that querying a Truck will generate a SQL statement with 20 joins!

And here comes the comments from those who shout that they hate NHibernate.