Getting started with Fluent NHibernate

Quite a few people have recommended NHibernate to me and because I am currently working on a new project, I decided to try it out. In the past, I’ve used the Data Access Layer (DAL) of the company I was working for. It was brilliant because it would take strongly typed data and return either a collection of your entities or a single entity to you based on what you were doing. That was all good except that it was difficult to customise the DAL. NHibernate seems a very good option but the learning curve is quite steep because you really need to understand how to set it up and configure your entities. The XML mapping is the hardest I’ve heard!

I like simple things and want to get on as quickly as I can with my project. When I researched, I found that the alternative to the laborious xml mapping was Fluent NHibernate. So I’m going Fluent now as I don’t want to be wasting time on writing XML mappings when Fluent NHibernate can do it for me and much more.

Creating your entity is pretty straightforward and doing the mapping is easy to digest as well. However the first time I tried to compile, I ended up with a few errors. Well I needed references to NHibernate.dll, FluentNHibernate.dll and NHibernate.ByteCode.Castle.dll (for lazy loading) to make the web app compile. All in all so far it was easy. It’s amazing that you can just do something like Session.SaveOrUpdate(customer) and your customer data is saved (less code is good). How wicked is that?

Now the problem for me was trying to figure out where NHibernate would be sitting in my application. It replaces the DAL, so do I just have a Business Logic Layer (BLL) now? How am I going to manage the NHibernate sessions? Many people have suggested that you create a session everytime there’s an HTTP request. So you basically write an HTTP module which would intercept all the requests to the web server and inject your logic in it, that is, create an NHibernate session when the request starts and close it when the request ends. The method works fine but I don’t want to be opening a session everytime there’s an http request, I’d rather open a session when I need information from the database. Therefore I’ve decided not to go down the HTTP module route but instead write an NHibernate Session Management class to handle the sessions. Note if you’re using AJAX, you’ll have problems with the HTTP module method because your session will be closed at the end of the request (when flushing out the content to the browser), so your ajax call will fail because there’s no session associated with the http request anymore.

Creating NHibernate sessions is an inexpensive task so you can create as many as you want and close them afterwards but creating the NHibernate SessionFactory object is what consumes the resources. It is therefore advisable to create the SessionFactory in Global.asax file so that it is only created once but available for the lifetime of the web application. Only when your web server reboots would the session factory object be recreated. The session factory would create in memory representation of your dabatase and the relationship between the tables.

Now all the entities share pretty much the same CRUD methods (Create, Retrieve, Update, Delete). Therefore it makes sense to use the Repository Pattern with NHibernate to make these methods available to all the entities. So if we create an IRepository interface, we could have the Repository do all the work for us as shown below:

IRepository<Employee> employees = new Repository<Employee>(sessionManager.OpenSession());
Employee employee = employees.GetById(7);
But what if we wanted to get the employees whose lastname are “smith”? Well then we are going to add to the repository an IQueryable method so that we can run custom queries through it.
public IQueryable<T> GetList(QueryBase<T> query)
return query.SatisfyingElementsFrom(Session.Linq<T>());
Of course we’ll need LINQ for NHibernate to help us out so that we can use expression trees. But this will allow us to send our custom queries through the repository now. Note that it is better to have a class for each query that we want, for example, a FindEmployeeByLastname class which would inherit from the QueryBase class to give us the desired query. This way you will not end up writing linq queries all throughout your application but rather have it in one single place so that you can easily maintain your application as it scales out.
This is the basis of how I’m going to use Fluent NHibernate in my next project and constitutes what I believe is the best for my web application through a week’s worth of research on the internet.
comments powered by Disqus