In my last post I wrote a little bit about the differances between NHibernate and Entity Framework. I came to the conclution that I, personaly, like NHibernate more then Entity Framework. So I tought I´d write a post that explains NHibernate more, and the reasons to why I choose it over other ORM´s.

As I wrote in a comment on my last post, I think a main feature of a ORM is to make the programer not think that he or she is acctually querying a database. This is very tricky, as the queries should be as optimiced as possible when they hit the database, while at the same time abstract the query away as much as possible. I feel that NHibernates ISession and criteria API does a very good job of hiding the database and keep the entities in focus of your application. At the same time, if you need to write a very complex query that will take time to execute, you can easily use a stored procedure for this query and execute it with NHibernate. If you find yourself with a lot of complex queries, then you might need to consider what you are acctually querying or maby think about another database option, like a object database. As relational databases are optimiced for selecting based on primary keys, and not as fast when there is alot of complex joins.

NHibernate does have a related framework in the java world aswell, Hibernate, that has been on the market for a while now. They work in a similar way. This is a good thing as the java community is a bit wider with a lot of good developers. This is essential for a open source project.

A good thing with NHibernate is that it´s pretty popular. This is good as it will involve many developers to build extensions for the framework. We do have extensions like Fluent NHibernate (mapping framework), Linq for NHibernate (linq implementation to give another querying option), NHibernate Search, NHibernate validation and more. Those are all very nice extensions that can help you alot when you develop a application. 

The mapping in NHibernate is separated from the object itself. Eather you choose to map in the classic way with one xml file for each class that describes how to persist it or you use Fluent NHibernate and map your application with plain C# code (or the language or your choise). This follows the rule, Seperation of Concern, in a nice way as the entity itself shouldn´t know how the underlaying database looks like and how it will be persisted.

NHibernate is a very fexible framework that can behave in a lot of different ways depending on your needs. You can easily go with a Repository pattern, you can implement a unit of work pattern very easily and pretty much do whatever you want with your ISession.

Another nice thing about NHibernate is the testability. If you use the FluentNHibernate.Framework library you have the ability to test your mappings in a nice way, as well as create a in-memory sqlite database that you can test your queries against. This is good, as you dont have to touch the acctuall database in order to test your data access layer. That will assure you that the database will allways look the same when you run your tests, and there is no specific order in wich the tests has to be run.

Those are a few reasons why I like NHibernate and why I think that it is a framework worth looking into if you haven´t allready. Feel free to add your opinions aswell or ask questions if anything is unclear. If you´d like to see how I implement NHibernate in a real application, you can check out my forum searies here. That is a searies of posts where I build a forum application using asp.net mvc with a NHibernate data access layer. You can download the source code from each post.