Why don't choose NHibernate

Well… I’m here again over the same matter… again performance.

This post is about some thoughts after this thread on nhusers list and not strictly a comparison between NHibernate vs EntityFramework.

The comparison

To compare performances I have used again the same environment and the same domain used in this post but, this time, with 50 companies having 50 employees having 50 reports; total entities 127550.

So far I’m NOT an expert in EntityFramework (I’m waiting for EF4) so I have used the same configuration Gergely Orosz have used in his performance test. The code used for NHibernate is the same of the previous post and the code used, to materialize all entities, for EntityFramework is the follow:

using (var ctx = new EFContainer())
{
  var companies = from c in ctx.EFCompanySet select c;
  foreach (var company in companies)
  {
      company.Employees.Load();
      foreach (var employee in company.Employees)
      {
          employee.Reports.Load();
      }
  }
}

The results of the test are

EntityFramework:

Store data seconds: 209,25 ( 209249 miliseconds)
Read data seconds: 57,77 ( 57773 miliseconds)

NHibernate:

Store data seconds: 24,29 ( 24287 miliseconds)
Read data seconds: 24,6 ( 24603 miliseconds)

Which is your conclusion ? NHibernate is faster than EntityFramework ? NHibernate is slow because the materialization of 127550 entities took 24.6” ?

That is what you are seeing ?

My conclusions

The first time I chose NHibernate was because:

• I’m looking for a persistent-layer based on ORM
• the license is LGPL
• its development is based on the mature, and standard de-facto, JAVA world persistent-layer: Hibernate

On what is based your daily work ?

TDD? DDD? code maintainability? business request? YAGNI? easy to implements? XP? dead-line? elegant-code solutions? performance? sprint?

If the performance is the most important concept why you are not programming using assembler instead C# ?

Are you applying only one of these concepts or your work is a continuous balance of each ?

What I’m seeing, in many teams, is that, for various reasons, we are loosing the most important concept: the balance of each.

In front of the question “why you chose this solution ?” many times the answer is “because the dead-line is tomorrow” or “because it is the minimal code to pass my test” and so on. The worst results is not the mere answer itself but what will happen after… perhaps when you have a performance issue. If you saw that the solution you have chose does not satisfy the expectance why, rethink the whole solution, shouldn’t be an option ?

Have a quick look to your toolbox perhaps you having the right tool to solve the issue. What ? using that tool the code is not elegant ? it will be more hard to maintain ? it is more hard to implements ?… and? which is the main target of that specific task ?

As you can see above a persistent-layer based on ORM is not the right tool to perform bulk operations, is not the right tool to perform massive data mining, is not the right tool to provide data for OLAP cube… this mean that a persistent-layer based on ORM is not a good tool ? absolutely NOT my friend, that only mean that in your application you have a lot of different tasks and you should choose the right tool for each specific task…have a look to your toolbox!!!