Click here to Skip to main content
Click here to Skip to main content

Simple NHibernate Architecture

, 11 Sep 2012
Rate this:
Please Sign up or sign in to vote.
An article showing a nice architecture I've come up for using NHibernate

Introduction

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 is 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.

Background

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 Architecture

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 (BusinessObject) encapsulates the common methods and properties all entities that need to be persisted have, like Save(), Delete(), ID, etc.

Here's a class diagram just to give an idea:

Screenshot - nh_classdiagram.jpg

The Implementation

The main classes on the NHibernateDAL project are the following:

  • NHibernateSessionManager – This is the class responsible for managing the NHibernate session. I've got this class from another NHibernate article on Code Project.

  • TransactionBlock – 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.

  • BusinessObject<T> - This is the base class for all the business entities I need to persist. It implements the basic CRUD methods.

Here's the code:

namespace Shared.NHibernateDAL
{
    public class BusinessObject<T>
    {
        public virtual void Save()
        {
            ISession session = NHibernateSessionManager.Instance.GetSession();
            if (!this.IsPersisted)
                session.Save(this);
            else
                session.SaveOrUpdateCopy(this);

            session.Flush();
        }

        public virtual void Delete()
        {            
            ISession session = NHibernateSessionManager.Instance.GetSession();
            session.Delete(this);
            session.Flush();
        }

        public virtual T Clone()
        {            
            return this.Clone();
        }

        /// <summary>

        /// Returns a valid populated object or a null reference        
        /// </summary>

        public static T Get(int id)
        {
            if (id <= 0)
                return default(T);
            else
            {
                ISession session = 
                    NHibernateSessionManager.Instance.GetSession();
                return session.Get<T>(id);
            }
        }

        private int _id;

        public virtual int ID
        {
            get { return _id; }
            set { _id = value; }
        }

        public virtual bool IsPersisted
        {
            get
            {
                return this.ID > 0;
            }
        }
    }
}

Using the Code

On this sample we are going to use a Product class to show the features.

Here's the Product class code:

namespace Business
{
public class Product : BusinessObject<Product>
{
    public Product()
    {
        this._name = null;
        this._weight = 0;
    }

    private string _name;
    private decimal _weight;

    public virtual decimal Weight
    {
        get { return _weight; }
        set { _weight = value; }
    }

    public virtual string Name
    {
        get { return _name; }
        set { _name = value; }
    }

    public static List<Product> Select()
    {
        ISession session = NHibernateSessionManager.Instance.GetSession();
        IQuery query = session.CreateQuery("from Product");
        return (List<Product>)query.List<Product>();
    }
}
}

Because all CRUD functionality is encapsulated on the BusinessObject, the domain entities are as simple as that. Now our Product class is ready to be consumed.

Note that I have included a static Select method that returns a list of products. This might be useful for populating user interface controls, but if you want to completely abstract NHibernate from your domain objects you should create another layer of abstraction under the business layer, containing all HQL queries. But, for small projects, I think it is OK to use HQL inside business objects.

The download file contains three projects, corresponding to the three layers I am using: NHibernateDAL, Business and Web. The Web project is a simple web page showing how easy it is to consume CRUD operations from the Product class.

Transactions

It is often necessary to use nested transactions with objects. You might have a method that opens its own transaction and sometimes needs to be called from another transaction. To solve this problem and also abstract the NHibernate transaction methods I've come out with the TransactionBlock class. This class keeps track of how many transaction blocks were open and ensures that only one transaction is opened on the database. At the end it commits the transaction only if all blocks were declared valid. Here's an example of its usage:

public void OutterTransaction()
{
    using (TransactionBlock tran = new TransactionBlock())
    {
        Product p1 = new Product();
        p1.Name = "Product 1";
        p1.Weight = 10;
        p1.Save();

        //Call another method with a transaction block
        InnerTransaction();

        tran.IsValid = true;
        // On the dispose call the database transaction is commited 
        //if all transaction blocks are valid
    }
}

private void InnerTransaction()
{
    using (TransactionBlock tran = new TransactionBlock())
    {
        Product p2 = new Product();
        p2.Name = "Product 2";
        p2.Weight = 10;
        p2.Save();                
        tran.IsValid = true;
    }
}

Conclusion

NHibernate has definitely helped me improve the quality and readability of my code. Combined with code generation tools (like MyGeneration), it can really improve productivity. But be aware, NHibernate and the architecture I am using will not fit every project. Working with legacy database can be a pain, although version 1.2 supports communication with stored procedures.

Any feedback will be greatly appreciated.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

About the Author

Cassio Mosqueira
Software Developer (Senior) Intelligent Coder
Canada Canada
I've been developing .NET enterprise applications since 2000.
 
I am originally from Rio de Janeiro and I am currently working at http://www.intelligentcoder.com in Ontario.

Comments and Discussions

 
GeneralWatch out for CallContext in TransactionBlock Pinmemberckinnan16-Aug-07 12:00 
On a different note, I just found your article and wanted to let you know that I liked your solution to the nested transaction problem. Providing the commit and rollback code in the dispose keeps the code a bit cleaner what with not needing the try catch and explicit begin, commit, rollback. Good job. We also implemented a transaction stack mechanism, but it relies on a more traditional try catch block.
 
To address the subject of this comment though, CallContext is not necessarily a safe place to put per thread values in a web environment. I'm not sure if that's what you're doing, but I figured I would pass this on as it caused us a bunch of problems in production. The problem is that a single web request is not guaranteed to live in a single thread context. I can't do the subject of context switching justice even if I took the time, but I'll drop a couple of links below.
 
Our solution was to check if HttpContext.Current != null. If it exists store items in HttpContext.Items, otherwise, use the CallContext: (sorry for the VB)
 
	
<System.Security.Permissions.SecurityPermission(System.Security.Permissions.SecurityAction.Demand, _ 
flags:=System.Security.Permissions.SecurityPermissionFlag.Infrastructure)> _
Public NotInheritable Class ContextCache
 
	Private Sub New()
 
	End Sub
 
	Public Shared Function GetData(ByVal key As String) As Object
		If System.Web.HttpContext.Current IsNot Nothing Then
			Return System.Web.HttpContext.Current.Items.Item(key)
		Else
			Return System.Runtime.Remoting.Messaging.CallContext.GetData(key)
		End If
	End Function
 
	Public Shared Sub SetData(ByVal key As String, ByVal value As Object)
		If System.Web.HttpContext.Current IsNot Nothing Then
			If System.Web.HttpContext.Current.Items.Contains(key) Then
				System.Web.HttpContext.Current.Items(key) = value
			Else
				System.Web.HttpContext.Current.Items.Add(key, value)
			End If
		Else
			System.Runtime.Remoting.Messaging.CallContext.SetData(key, value)
		End If
	End Sub
 
End Class
http://piers7.blogspot.com/2005/11/threadstatic-callcontext-and_02.html[^] Good overall description of the context switching problem.
http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/#S6[^] Microsoft's recommendation at #5.
 
Hope you find this useful.
GeneralRe: Watch out for CallContext in TransactionBlock PinmemberCassio Alves17-Aug-07 4:59 
GeneralRe: Watch out for CallContext in TransactionBlock PinmemberChuck Kinnan17-Aug-07 6:14 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web02 | 2.8.140721.1 | Last Updated 11 Sep 2012
Article Copyright 2007 by Cassio Mosqueira
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid