By Cassio Alves.
I started using NHibernate at the end of last year and I am having a wonderful experience with it. The simple fact that I don’t have to maintain hundreds of procedures and data access abstraction classes to do basic CRUD operations is enough to justify the use of NHibernate (even though I used a custom code generation tool). Besides that, my code is amazingly clearer and simpler. I only need to worry about business and user interface logic now. All that pluming code has gone for good.
I had zero experience with ORM frameworks, so on the first couple of weeks using NHibernate I had a hard time with some issues, like using it with ASP.NET disconnected objects and abstracting NHibernate sessions from the domain layer. After putting in some effort I came out with a nice architecture that abstracts the NHibernate layer and allows me to work with an ASP.NET session.
I am assuming you already have some familiarity with NHibernate. If you are new to NHibernate I encourage you to go to the website and download the reference documentation. I am using NHibernate 1.2 CR1 in this article.
The idea here is to keep my business objects unaware of an NHibernate session. So I created a different project for NHibernate stuff, called Shared.NHibernateDAL. It includes the session and transaction manager classes. I also created a common business object that serves as a base class for all my business entities. This class (
) encapsulates the common methods and properties all entities that need to be persisted have, like
Here’s a class diagram just to give an idea:
The main classes on the NHibernateDAL project are the following:
– This is the class responsible for managing the NHibernate session. I’ve got this class from another NHibernate article on Code Project.
– This is a class I created to manage transactions and abstract it from NHibernate. I will show an example of its use further on this article.
– This is the base class for all the business entities I need to persist. It implements the basic CRUD methods.