Ayende @ Rahien

My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:


+972 52-548-6969

, @ Q c

Posts: 6,026 | Comments: 44,842

filter by tags archive

The NHibernate Community

time to read 1 min | 88 words

In response to Davy's post about the rise of interesting in NHibernate,I decided to run the numbers.

Nine months ago we created the NHibernate Users, which has taken off quite nicely, with over thousand members and a very active community.


For that matter, the stats for NHibernate downloads are quite nice as well.


The dip just toward the end is just before we released NHibernate 2.0.



Tuna Toksoz

Moreover, the interest in NHForge is rising too. Just check the google analytics

Patrick Smacchia

This is great news, congratulation for this tremendous success!

However, when I analyzed the NH code base with NDepend I figured out that 63 namespaces on 65 depend (directly or indrectly) on all others namespaces.


In other words, there is no layering nor componentization strategy. As a consequence the code base is a big plate of spaghettis. Juts have a look at this dependency matrix if you don't believe me:


NH developers and users can live with that (for a while at least) but IMHO it fosters bad practices amongst the community. Read this post for example:


I quote

"Who care if namespaces are cross dependent? I don’t. Namespaces are for logical groupings of behaviors. If your behaviors are cross dependent, so will your namespaces."

Huh :o/

Tuna Toksoz

Patrick, the real reason behind this is the java brother hibernate. This is not an excuse, of course, but i think this is the thing.

Fabio Maulo

@Patrick Smacchia

I'm Italian and I like spaghetti.

BTW I would like to see the injectability, extensibility, less dependency of NHibernate in many others projects.

Patrick Smacchia

Tuna, no this is no excuse indeed. It is still time to make the right abstractions and rationalize the dependencies.

Fabio, my family name is Smacchia, from Perugia, and I love Spaghetti too as long as I can eat them :o)

Fabio Maulo


Take a look on the left-top of this page.

A simple critic is not enough and become something heavy when is repeated again and again without a solution.

If you don't like something, do your better to change it or accept it.

Gokhan Demir

btw summer of nhibernate casts are also help a lot of people to dive into nhibernate world. At least for my colleagues :)

Steve Bohlen

I think what we are seeing here is exactly what I would have predicted would come from MS trying to enter the O/RM space with Entity Framework: all kinds of developers who previously had no idea there even WAS an acronym 'O/RM' are becoming 'aware' of the category's existence and exploring the space to see what its all about.

As they explore EF they either become aware of alternates due to general 'buzz' in the air about other choices (like NHib, LLBLGEN, etc) or else they try to use EF in a non-trivial, non-demo situation and rapidly bump into some of its more aggregious limitations.

Just as MS providing UNITY as an IoC container has opened the eyes of many to what IoC stands for and why they might want to consider an IoC container to assist them in their work, the same phenomenon is manifesting itself in the O/RM space as well (IMHO).

NHibernate, by providing a viable alternate to EF that handily addresses many of the EF shortcomings, is in a good position to offer a practical, useful alternate that is available and solves problems for people who have to produce real software solutions TODAY rather that at some future, indeterminate point when MS may have gotten around to extending EF to resolve some of its present foibles.

Its a testament to the efforts of both past and present NHibernate contributors that a (comparatively) small band of independent OSS contributors has managed to produce a piece of software with capabilities that even something that is now an actual part of the .NET framework BCL cannot match in re: capability, flexibility, or extensibility. This is the (largely) unheralded story of NHibernate -- not that it was 'there first', but that even now it remains in most ways that matter a significantly better O/RM tool that even Microsoft has yet to produce.

Patrick Smacchia

A simple critic is not enough and become something heavy when is repeated again and again without a solution.

Fabio , the critic is not simple since it comes with proven facts such as this dependency matrix:


My only concern is the fact that very popular OSS code bases such as the one of NH should promote good coding style such at the very least good componentization and layering. Beside that, I am sure that the NH code base comes with great things such as injectability, extensibility...

If you don't like something, do your better to change it or accept it.

At our level, the only thing we (the NDepend team) can do to help on this, is to give free license of NDepend to OSS developers. Also, here I wrote an article to explain how we layerized the NDepend code base itself:


Sidar Ok

Abundance of Linq to SQL has also a good effect in this, imho.

Sidar Ok

Should have been L2S being abondoned :)

Fabio Maulo


You had jumped the first phrase.

"Take a look on the left-top of this page."

Translated mean:

"Send me a patch for this"


Patrick, of course it would be good for NH to promote good coding styles. But who is going to make it happen?

Not Fabio, as he has enough on his plate and is already doing great work for NH.

Not me, because I don't care enough.

Maybe you can do it? Apparently you think it is very important?

If you think NH should have better componentization, you should make the effort.

Many people want important things to happen, but when replied 'please do it yourself' it suddenly isn't that important anymore.

(BTW I love NH and it's codebase, and I love NDepend too!)

Patrick Smacchia

Alwin, Fabio, apologize for the misunderstanding.

Like you I am currently buried under work but yes, it would be nice to componentize the NH code base. From my experience, componentizing is not something too time consumming. The reason is that developers instinctively know what is high and low level and usually avoid doing call from low level to high level. But any code base ands up being roted more or less because this 'instinct' cannot replace a rigorous check with a tool. I would estimate a week of work for the 36K LoC of the NH project.

By looking at the DSM of direct dependencies...


I think NHibernate, NHibernate.Engine, NHibernate.Utils, NHibernate.Types are the 4 low level components and the first thing to do is to eliminate their efferent dependencies, menaning they should not use any high level component. Concretely their black cell in their respective rows should become blue. This is done usually by creating interfaces and doing injection of code. Also a level order must be defined amongst these 4 namespaces.

Comment preview

Comments have been closed on this topic.


No future posts left, oh my!


  1. Technical observations from my wife (3):
    13 Nov 2015 - Production issues
  2. Production postmortem (13):
    13 Nov 2015 - The case of the “it is slow on that machine (only)”
  3. Speaking (5):
    09 Nov 2015 - Community talk in Kiev, Ukraine–What does it take to be a good developer
  4. Find the bug (5):
    11 Sep 2015 - The concurrent memory buster
  5. Buffer allocation strategies (3):
    09 Sep 2015 - Bad usage patterns
View all series


Main feed Feed Stats
Comments feed   Comments Feed Stats