NHibernate blog

NHibernate and WPF: The GuyWire

Jose Romaniello — Sat, 07 Nov 2009 19:12:52 GMT

Note: I owe this knowledge to my friend Fabio Maulo, so I would like to thank him for teaching me and letting me share.

Introduction

I will show you in this post a nice way to configure your IoC container and some other aspects of your applications. I assume for this article that you have good knowledge of dependency injection and inversion of control.

The problem

There was a time when we used to configure our containers with xml, and all was fine. Then we started to use fluent and strongly typed interfaces and a problem became more frequent and acute. Basically, when we use a fluent interface, we do something like this:

container.Register(Component.For<IAlbumRepository>()
                       .ImplementedBy<AlbumRepository>()
                       .LifeStyle.Transient);

IAlbumRepository is in Chinook.Data and AlbumRepository is in Chinook.Data.Impl.
The problem is not *how* but *where*. Where do you do this?

Most people will say “The startup project”. One of the goal that we look when using IoC is:

..decoupling of the execution of a certain task from implementation.

Pay attention to the “Decoupling” part. If you want “decoupling”: Why do you add all those references in your startup project?

This is a NDepend extracted graph of the Northwind example that comes with Sharp Architecture:

If you look at the Northwind.Web assembly you will see that it has a reference even to NHibernate. It has a reference to Northwind.Data (repositories that use NHibernate). The contract interface of repositories is in Northwind.Core. Also you can see that the start up project need a reference to Castle Container. If I want a loosely coupled solution, I don’t want some of those references.

Pay atention; the northwind example of Sharp Architecture is a very good example, is a good architecture, and this is neither a complain nor a criticism. I’m pretty sure that it defines interfaces and implementations separately, as I’m pretty sure that controllers depends upon IRepositories. But, I think it has a problem at reference level. The main problem is because the initialization of the container is in a wrong place. You could see the initialization script here.

So, what I’m looking for is:

I don’t want references to concrete implementations in my startup project.
I don’t want to depend upon a specific IoC container technology.
And finally I don’t want to configure my container in the startup project, its is another “aspect” of my application like the repositories!

The Solution

The solution is very simple. Take the container initialization to another place.

We used to call this place “The GuyWire”, in italian “Cavo Portante”, in spanish “Cable Maestro”:

A guy-wire or guy-rope is a tensioned cable designed to add stability to structures

Two simple rules to remember:

In order to configure service and implementers fluently, the GuyWire will reference everything.
Because the guy-wire reference everything, the GuyWire can not be referenced.

The guywire is an excellent place to “configure” the whole application. I used to separate the configuration in different aspects. Here some examples:

ORM configuration
Constraint Validator configuration
Repositories configuration
Entities configuration
ViewModel configuration
Controllers configuration
Views configuration

You can explore the configurators of ChinookMediaManager here.

How does it works?

The guywire project has an special “Output Path”:

So, the path is the “Startup” project.

Secondly, in the App.Config, I have a config like this:

<appSettings>
  <add key="GuyWire" value="ChinookMediaManager.GuyWire.GeneralGuyWire, ChinookMediaManager.GuyWire" />
</appSettings>

And finally, in my App.Xaml.cs:

public partial class App : Application
{
    private readonly IGuyWire guyWire = ApplicationConfiguration.GetGuyWire();

    public App()
    {
        guyWire.Wire();
    }

    protected override void OnStartup(StartupEventArgs e)
    {
        var viewFactory = ServiceLocator.Current.GetInstance<IViewFactory>();
        viewFactory.ShowView<BrowseArtistViewModel>();
    }

    protected override void OnExit(ExitEventArgs e)
    {
        guyWire.Dewire();
        base.OnExit(e);
    }
}

The interface IGuyWire and other classes needed for doing this, are in unhaddins.

The reference graph of the Chinook Media Manager, is as follows:

A last word about the Configurators

I really like the idea of have different parts of the application configuration in separated classes. I used to reuse this configurators alone in my Tests. But, as a I said before, the guywire should not be referenced by any project. So, my trick is add the configurator as a “linked file” to the test project:

And this is a sample:

[TestFixture]
public class AlbumValidationFixture
{
    private IWindsorContainer container;

    [TestFixtureSetUp]
    public void FixtureSetUp()
    {
        container = new WindsorContainer();
        var configurator = new NHVConfigurator();
        configurator.Configure(container);
    }

    [Test]
    public void title_constraints()
    {
        GetConstraint<Album, NotEmptyAttribute>(a => a.Title)
            .Message
            .Should().Be.EqualTo("Title should not be null.");

        GetConstraint<Album, LengthAttribute>(a => a.Title)
            .Should().Be.OfType<LengthAttribute>()
            .And.ValueOf.Message.Should().Be.EqualTo("Title should not exceed 200 chars.");
            
        
    }
}

I will not talk about this long break in the series. If you are interested in Wpf and Nhibernate, you should be happy because; I'M BACK!

NHibernate Validator 1.2 Beta3 released

Dario Quintana — Mon, 26 Oct 2009 16:12:00 GMT

Download NHibernate Validator 1.2 beta3 with sources, binaries and example here here

For use it with NHibernate 2.1 GA.

For examples and documentation see the serie of blog posts of Fabio Maulo about NHibernate Validator here

hbm2net

felicepollano — Mon, 19 Oct 2009 07:43:00 GMT

I did an attempt of resuming the project hbm2net, creating a Text Template Transformation Toolkit (T4) renderer, hosting the T4 engine. T4 templates allow to easily mix templates with additional code.The current version is not production code, but a proof-of-concept. If anyone interested a download is provided, containing the source and a single unit test to show the idea. A ready to use binary version could be found here (post is in italian, but is easy to grasp how to try it),as I said, it is not tested for production. Please let me know if the idea is useful / interesting.

Mapping different types - IUserType

Krzysztof Kozmic — Thu, 15 Oct 2009 18:21:00 GMT

Recently I had a problem with the application I’ve been working on. One of entity types in my domain had a property of type uint. Not a big deal, until you want to store it in Microsoft SQL Server database which does not support unsigned types. I’ve been scratching my head for a moment and then I found a solution – let’s map it as long in our database. Since long can represent any legal value of uint, we should be all good, right? So let’s do it.

public class ClassWithUintProperty

    private Guid Id { get; set; }

    public virtual uint UintProp { get ;set; }

<?xml version="1.0"?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"

                   assembly="NHibernate.Test"

                   namespace="NHibernate.Test">

  <class name="ClassWithUintProperty">

    <id name="Id"/>

    <property name="UIntProp" not-null="true" type="long" />

  </class>

</hibernate-mapping>

"Houston, we've had a problem"

All good. At least until you try to fetch saved value from the database. When you do, you’re up for an unpleasant surprise:

System.InvalidCastException: Specified cast is not valid.

NHibernate.PropertyAccessException: Invalid Cast (check your mapping for property type mismatches); setter of NHibernate.Test.UIntAsLong

The exception is a result of how NHibernate optimizes property access and quirks of mixing different conversion operators (unboxing and numeric conversion in this case) and are not really interesting. What’s important, is that we approached the problem from the wrong angle.

What we’re dealing with here, is inability of our database engine to deal with datatype in our model, which we were trying to solve by pushing this onto NHibernate without telling it something is ‘”wrong”. While NHibernate is smart, it’s working based on a set of explicit information, so what we need to do, is to be explicit about what we want it to do.

There are two places where we can tell NHibernate about it.

IUserType, which will explicitly handle the mapping from uint in our model to long in the DB
custom Dialect which will basically lie to NHibernate telling it “yeah, sure this DB supports uints – whole dozens of ‘em!” and do some work under the covers to live up to its promise. (not shown in this post).

Enter IUserType

IUserType is an extension point in NHibernate that let’s you plug in to the mapping process and handle it yourself. The interface is quite big, but there’s very little real logic there:

public class UIntAsLong:IUserType

        public SqlType[] SqlTypes

            get { return new[] { SqlTypeFactory.Int64 }; }

        public Type ReturnedType

            get { return typeof( uint ); }

        public bool IsMutable

            get { return false; }

        public int GetHashCode( object x )

            if( x == null )

                return 0;

            return x.GetHashCode();

        public object NullSafeGet( IDataReader rs, string[] names, object owner )

            object obj = NHibernateUtil.UInt32.NullSafeGet( rs, names0 );

            if( obj == null )

                return null;

            return (uint)obj;

        public void NullSafeSet( IDbCommand cmd, object value, int index )

            Debug.Assert( cmd != null);

            if( value == null )

                ((IDataParameter)cmd.Parametersindex).Value = DBNull.Value;

            else

                var uintValue = (uint)value;

                ( (IDataParameter) cmd.Parametersindex ).Value = (long) uintValue;

        public object DeepCopy( object value )

            // we can ignore it...

            return value;

        public object Replace( object original, object target, object owner )

            // we can ignore it...

            return original;

        public object Assemble( object cached, object owner )

            // we can ignore it...

            return cached;

        public object Disassemble( object value )

            // we can ignore it...

            return value;

        bool IUserType.Equals( object x, object y )

            return object.Equals( x, y );

There are really two parts of the code that are interesting. SqlTypes / ReturnedType properties which tell NHibernate which types to expect on both sides of the mapping, and the NullSafeGet / NullSafeSet methods which perform the actual conversion.

Now we just need to plug our custom user type to the mapping, and it goes like this:

<?xml version="1.0"?>

<hibernate-mapping xmlns="urn:nhibernate-mapping-2.2"

                   assembly="NHibernate.Test"

                   namespace="NHibernate.Test">

  <class name="ClassWithUintProperty">

    <id name="Id"/>

    <property name="UIntProp" not-null="true" type="Foo.Namespace.UIntAsLong, Foo.Assembly" />

  </class>

</hibernate-mapping>

NHibernate Validator 1.2 Beta2 released

Dario Quintana — Sat, 10 Oct 2009 18:16:00 GMT

Download NHibernate Validator 1.2 beta2 with sources, binaries and example here here

For use it with NHibernate 2.1 GA.

Enjoy it !

Part 10: Testing and Refactoring

Jason Dentler — Sun, 20 Sep 2009 19:07:41 GMT

~~Today’s post will be short~~. I’m going to cover the basics of testing with Rhino Mocks and do some refactoring in the DAOs.

I’m not an expert. This is just how I do things. If you have a better way, do it your way. Better yet, tell me about it so I can improve the way I work as well.

Testing Terminology

In recent years, testing vocabulary has exploded. There are mocks and stubs and fakes and unit tests and integration tests and acceptance tests and all sorts of jargon. You may be thinking “who cares?” This jargon is only important when code needs to communicate its intent to humans, right?. The compiler doesn’t care what terminology we use. Well, sorry. Code is written for humans, not compilers, so programming jargon is a prerequisite.

Test Doubles

So, let’s go over some common terms. I’m going to lift these definitions straight from Marton Fowler’s Mocks Aren’t Stubs. Test Double is a “generic term for any kind of pretend object used in place of a real object for testing purposes.” That’s pretty straight forward. Test doubles come in four types:

Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.

Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).

Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what's programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it 'sent', or maybe only how many messages it 'sent'.

Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

Hi. Still with me? Good.

Mocks are significant. They are part of the “proof” of the test. The other three amount to plumbing. Now, you may be asking your self why we even need test doubles. Why can’t we just run our production code and inspect the output? Fowler’s article has several sections about the differences and pros and cons of classical testing (using objects from the real code) vs. mockist testing (creating doubles for everything except what you’re testing).

Even in classical testing, you sometimes have to swap in a test double for objects that lead to permanent side effects or operate too slowly. In mockist testing, you swap in test doubles for everything that you’re not explicitly testing. Either way, you need to know how to create and use test doubles.

We’re going to use Rhino Mocks, a fluent framework for creating stubs and mocks. I don’t know if it’s the best, but if Ayende wrote it, you can bet it’s pretty darn awesome. Plus, the fluent syntax works OK in VB.NET, which is rare.

Writing the Test

Suppose we had a standard GetByID function on our DAO (because we do) containing some code like this (because it does). How would we test that the function actually did what it claimed?

        If m_Session.Transaction Is Nothing OrElse Not m_Session.Transaction.IsActive Then
            Dim RetVal As TEntity
            Using Tran = m_Session.BeginTransaction
                RetVal = m_Session.Get(Of TEntity)(ID)
                Tran.Commit()
                Return RetVal
            End Using
        Else
            Return m_Session.Get(Of TEntity)(ID)
        End If

            if (null == m_Session.Transaction || !m_Session.Transaction.IsActive)
            {
                TEntity retval;
                using (var Tran = m_Session.BeginTransaction())
                {
                    retval = m_Session.Get<TEntity>(ID);
                    Tran.Commit();
                    return retval;
                }
            }
            else
            {
                return m_Session.Get<TEntity>(ID);
            }

Because I’m not an expert, I won’t try to explain the computer science of testing. I can tell you that if we ignore possible branches inside NHibernate objects, there are two possible paths through our function (the first if we don’t have an existing explicit transaction, and the second if we do), giving us a cyclomatic complexity of 2. This means that we need two unit tests to achieve 100% code coverage. 100% code coverage doesn’t mean perfect code, but it helps.

I prefer the Record / Playback style of testing. In this style, you start by setting up your expectations within a record section – which mock methods will be called, how many times they’ll be called, in what order they’ll be called, and what their return values should be. Then, in the playback section, you perform the actual action. In this case, we’ll create an instance of our DAO and call its GetByID method. Finally, you verify that the expectations of your mock were met, as well as any other assertions you may need to prove.

Edit: The alternative to Record / Playback is Arrange / Act / Assert. If you don’t know the difference, here’s a good article Jose sent me. Rhino Mocks supports both styles. I still prefer Record / Playback, probably just because I’m used to it.

Here’s what a test of GetByID with a pre-existing transaction would look like:

    <Test()> _
    Public Sub GetByIDTest()
        Dim mocks As New MockRepository()
        Dim session As NHibernate.ISession = mocks.StrictMock(Of NHibernate.ISession)()
        Dim transaction As NHibernate.ITransaction = mocks.Stub(Of NHibernate.ITransaction)()
        Dim expected As Student = mocks.Stub(Of Student)()
        Dim actual As Student
        Using mocks.Record()
            Rhino.Mocks.Expect.Call(session.Transaction).Return(transaction).Repeat.Any()
            Rhino.Mocks.Expect.Call(transaction.IsActive).Return(True)
            Rhino.Mocks.Expect.Call(session.Get(Of Student)(Guid.Empty)).Return(expected)
        End Using

        Using mocks.Playback()
            Dim StudentDao As IReadStudent = New StudentDaoImpl(session)
            actual = StudentDao.GetByID(Guid.Empty)
        End Using
        mocks.VerifyAll()
        Assert.IsNotNull(actual, "null entity returned")
        Assert.AreSame(expected, actual, "wrong entity returned")
    End Sub

        [Test]
        public void GetByIDTest()
        {
            MockRepository mocks = new MockRepository();
            NHibernate.ISession session = mocks.StrictMock<NHibernate.ISession>();
            NHibernate.ITransaction transaction = mocks.Stub<NHibernate.ITransaction>();
            Student expected = new Student();
            Student actual;
            using (mocks.Record())
            {
                Rhino.Mocks.Expect.Call(session.Transaction)
                    .Return(transaction)
                    .Repeat.Any();
                Rhino.Mocks.Expect.Call(transaction.IsActive)
                    .Return(true);
                Rhino.Mocks.Expect.Call(session.Get<Student>(Guid.Empty))
                    .Return(expected);
            }
            using (mocks.Playback())
            {
                IReadStudent StudentDao = new StudentDAOImpl(session);
                actual = StudentDao.GetById(Guid.Empty);
            }
            mocks.VerifyAll();
            Assert.IsNotNull(actual);
            Assert.AreSame(expected,actual);
        }

We start by creating a MockRepository. This is the factory for all of our mocks and stubs, controls our record and playback blocks, and verifies that all the mock expectations have been met.

Next, we create a mock of the NHIbernate session and a stub of an NHibernate transaction. We create a mock because we want to make sure our DAO calls m_Session.Get<>. We also create a double for our return value called expected. We’ll compare it to the actual return value.

Now that we have our doubles, we set up our expectations. We are testing the path of the pre-existing transaction. Session.transaction will return our transaction stub. Since this is a mock, not a stub, the default is to assert that it is called exactly once. Since we’re not interested in this part, we specify that it can be called any number of times. We also specify that a call to transaction.IsActive should return true. Finally, we specify that our DAO will call session.Get<> exactly once, and that our mock session should return our expected student.

Next, we start our playback block and perform the action. We create an instance of our DAO, passing in the mock session we wired up in our record block, and we call GetByID.

Finally, we verify that our DAO interacted with the stub as expected. We also assert that the actual instance returned during our test is the same as our expected instance.

This covers the first test. What about the second one? Well, the test would be identical except for your expectations. We would setup our transaction stub so that transaction.IsActive returned false. We would also expect our DAO to call session.BeginTransaction().

Now, I’m lazy and we’ve already done things backwards by writing our code before our tests, so let’s continue being lazy. I don’t want to write two tests for each DAO method just because of some transaction handling code, which by the way, is repeated all over the place. Not good. Let’s refactor things a bit.

Refactored Transaction Handling

In all of the DAO methods, I’ve made the choice to ensure we have an explicit transaction before interacting with the database. In previous versions, each method is nearly identical to the code we tested above above.

In all of this, the only unique code is the call to m_Session.Get(). The rest of the code is just uninteresting transaction handling, and this uninteresting plumbing code is repeated in every method of our DAO. Let’s pull it out in to its own function.

    Protected Function WrapInTransaction(ByVal F As Func(Of TEntity)) As TEntity
        Return WrapInTransaction(Of TEntity)(F)
    End Function

    Protected Function WrapInTransaction(Of TResult)(ByVal F As Func(Of TResult)) As TResult
        If m_Session.Transaction Is Nothing OrElse _
            m_Session.Transaction.IsActive = False Then
            Using Tran = m_Session.BeginTransaction
                Dim RetVal As TResult = F.Invoke()
                Tran.Commit()
                Return RetVal
            End Using
        Else
            Return F.Invoke()
        End If
    End Function

        protected TEntity WrapInTransaction(System.Func<TEntity> F)
        {
            return WrapInTransaction<TEntity>(F);
        }

        protected TResult WrapInTransaction<TResult>(System.Func<TResult> F)
        {
            if (null == m_Session.Transaction || !m_Session.Transaction.IsActive)
            {
                using (NHibernate.ITransaction Tran = m_Session.BeginTransaction())
                {
                    TResult RetVal = F.Invoke();
                    Tran.Commit();
                    return RetVal;
                }
            }
            else
            {
                return F.Invoke();
            }
        }

Now we can pass in the small-but-interesting bit of code as a parameter to the WrapInTransaction method. This lets us simplify our methods down to this:

    Public Function GetByID(ByVal ID As System.Guid) As TEntity Implements IRead(Of TEntity).GetByID
        Return WrapInTransaction(Function() m_Session.Get(Of TEntity)(ID))
    End Function

        public TEntity GetById(System.Guid ID)
        {
            return WrapInTransaction(() => m_Session.Get<TEntity>(ID));
        }

It’s shorter. Some might argue that it’s not as readable since it uses lambda syntax. In this case, I think DRY (don’t repeat yourself) is more important. To be honest, I’m not sure if this cuts the cyclomatic complexity of our methods in half, but It certainly lets us write about 1/2 as many tests and still have 100% coverage. We just need to write our already-have-a-transaction and wrap-in-transaction tests once period, instead of once per method.

If you’re working in C#, you can create another overload that accepts a System.Action (System.Func but returning void). In Visual Basic.NET, this would be a Sub, but unfortunately, there’s no lambda syntax for calling a Sub in VB.NET. To get around this, I’ve updated our Save method to this:

    Public Function Save(ByVal Entity As TEntity) As TEntity Implements ISave(Of TEntity).Save
        Return WrapInTransaction(Function() SaveOrUpdate(Entity))
    End Function

    Private Function SaveOrUpdate(ByVal Entity As TEntity) As TEntity
        m_Session.SaveOrUpdate(Entity)
        Return Entity
    End Function

Since we're returning a value, we can use our existing WrapInTransaction(Func<>) method. The download includes tests for all of our DAO methods, including WrapInTransaction.

That’s it for part 10. For homework, write the tests for our StudentDaoImpl class. Hints: Use a fake, verify that it returns what it should, and verify that it doesn’t return what it shouldn’t.

I’ve changed the SQLiteDatabaseScope to match my previous post, and pulled it in to its own project.

Download the entire solution in VB.NET or C#.

In part 11, we’ll dive in to validation.

Jason

Part 9: NHibernate transactions

Jason Dentler — Tue, 08 Sep 2009 13:26:05 GMT

In this part, we’re going to wrap our NHibernate transactions and create a factory for them so we can use them in higher layers without referencing NHibernate all the way up.

If you’re new to the series, you can read Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, and Part 8 to catch up.

You may have noticed in part 8 that in each DAO method, if we didn’t already have an explicit transaction, I created one around each database interaction. My reason for this is explained in Ayende’s NHibernate Profiler alert “Use of implicit transactions is discouraged.” This works great for simple DB interaction, but what about the more complex scenarios?

This is where we get to talk about this great thing called a business transaction. So once again, I’m going to parade out my experts. Actually, this time it’s only Udi Dahan. There are two key points he’s written about on his blog.

Partial failures can be good. The programmer in all of us sees that and screams atomicity. Transactions should be all-or-nothing. Anything less is just wrong. Right? In real life, there are instances where we allow, and even prefer partial failures of business transactions. Udi gives us a great example. Would you leave the grocery store empty handed simply because they were out of one item on your list? Probably not. When you’re gathering requirements, be sure to ask questions about the proper way to fail. “Roll it all back” isn’t the only option.
Realistic Concurrency – The entire post is worth reading, but Udi makes one point I want to touch on specifically. When performing an operation for the user, you should get the current state, validate, and then perform the task all within the business transaction.

Let’s use our college application as an example. We have a user story / use case / requirement / story card / whatever to allow students to register for classes, provided those classes aren’t full. If you’ve ever worked at or attended a college or university where certain classes always have more demand than available seats, you are no doubt aware of how quickly those classes will fill up. In fact, the best sections (best professors and best times) can fill up just minutes after registration is opened. It’s very possible that dozens of potential students could access the section when there is only a few seats left. Since the enrollment in a particular section (the current state) changes so rapidly, you must obtain a lock, refresh your enrollment numbers and make sure there is room (revalidate) before actually enrolling that student. If more than one registration request is received, they should be performed serially.

The process is:

Open a transaction at the proper isolation level. Consult your nearest DBA, as isolation levels are outside the scope of this series.
Refresh – Get the current state of the entity
(Re)Validate – Be sure the business transaction is still valid for the current state
Execute – Perform the insert / update / delete
Commit the transaction

Now that we’ve covered business transactions, let’s get set up to use them in our business logic. We shouldn’t have NHibernate types floating around at that level, so we’ll wrap them. Once again, the interfaces go in the Data namespace of the core project and the implementations go in the Data project.

Imports System.Data

Namespace Data

    Public Interface ITransactionFactory

        Function BeginTransaction() As ITransaction
        Function BeginTransaction(ByVal IsolationLevel As IsolationLevel) As ITransaction

    End Interface

End Namespace

Namespace Data

    Public Interface ITransaction
        Inherits IDisposable

        Sub Commit()
        Sub Rollback()

    End Interface

End Namespace

Imports NHibernate

Public Class TransactionFactoryImpl
    Implements ITransactionFactory

    Public Sub New(ByVal Session As ISession)
        m_Session = Session
    End Sub

    Protected ReadOnly m_Session As ISession

    Public Function BeginTransaction() As ITransaction Implements ITransactionFactory.BeginTransaction
        Return New TransactionWrapper(m_Session.BeginTransaction)
    End Function

    Public Function BeginTransaction(ByVal IsolationLevel As System.Data.IsolationLevel) As ITransaction Implements ITransactionFactory.BeginTransaction
        Return New TransactionWrapper(m_Session.BeginTransaction(IsolationLevel))
    End Function

End Class


Imports NHibernate

Public Class TransactionWrapper
    Implements ITransaction

    Public Sub New(ByVal Transaction As NHibernate.ITransaction)
        m_Transaction = Transaction
    End Sub

    Protected ReadOnly m_Transaction As NHibernate.ITransaction

    Public Sub Commit() Implements ITransaction.Commit
        m_Transaction.Commit()
    End Sub

    Public Sub Rollback() Implements ITransaction.Rollback
        m_Transaction.Rollback()
    End Sub

    Private disposedValue As Boolean = False        ' To detect redundant calls

    ' IDisposable
    Protected Overridable Sub Dispose(ByVal disposing As Boolean)
        If Not Me.disposedValue Then
            If disposing Then
                ' TODO: free other state (managed objects).
                m_Transaction.Dispose()
            End If

            ' TODO: free your own state (unmanaged objects).
            ' TODO: set large fields to null.
        End If
        Me.disposedValue = True
    End Sub

#Region " IDisposable Support "
    ' This code added by Visual Basic to correctly implement the disposable pattern.
    Public Sub Dispose() Implements IDisposable.Dispose
        ' Do not change this code.  Put cleanup code in Dispose(ByVal disposing As Boolean) above.
        Dispose(True)
        GC.SuppressFinalize(Me)
    End Sub
#End Region

End Class

using System.Data;

namespace NStackExample.Data
{
    public interface ITransactionFactory
    {

        ITransaction BeginTransaction();
        ITransaction BeginTransaction(IsolationLevel isolationLevel);

    }
}

using System;

namespace NStackExample.Data
{
    public interface ITransaction : IDisposable 
    {
        void Commit();
        void Rollback();
    }
}

using System.Data;
using NHibernate;

namespace NStackExample.Data
{
    public class TransactionFactoryImpl : ITransactionFactory 
    {

        public TransactionFactoryImpl(ISession Session)
        {
            m_Session = Session;
        }
        
        protected readonly ISession m_Session;

        #region ITransactionFactory Members

        public ITransaction BeginTransaction()
        {
            return new TransactionWrapper(m_Session.BeginTransaction());
        }

        public ITransaction BeginTransaction(IsolationLevel isolationLevel)
        {
            return new TransactionWrapper(m_Session.BeginTransaction(isolationLevel));
        }

        #endregion
    }
}


using System;
using NHibernate;

namespace NStackExample.Data
{
    public class TransactionWrapper : ITransaction
    {

        public TransactionWrapper(NHibernate.ITransaction Transaction)
        {
            m_Transaction = Transaction;
        }

        protected readonly NHibernate.ITransaction m_Transaction;

        #region ITransaction Members

        void ITransaction.Commit()
        {
            m_Transaction.Commit();
        }

        void ITransaction.Rollback()
        {
            m_Transaction.Rollback();
        }

        private bool disposedValue = false;

        protected override void Dispose(bool Disposing)
        {
            if (!this.disposedValue)
            {
                m_Transaction.Dispose();
            }
            this.disposedValue = true;
        }

        public void Dispose()
        {
            Dispose(true);
            GC.SuppressFinalize(this);
        }

        #endregion
    }
}

You may be interested to know that the NHibernate ITransaction will perform an implicit rollback when it is disposed, unless an explicit call to Commit or Rollback has already occurred. To implement this behavior, we implement IDisposable in our transaction wrapper and chain our wrapper’s Dispose to NHibernate.ITransaction’s Dispose. This implicit rollback can indicate a missing call to Commit, so it generates an alert in NHibernate Profiler. If you intend to rollback, do it explicitly. Your code will be easier to understand.

That’s it for part 9.

Jason
- Off to mow the lawn.

Part 8: DAOs, Repositories, or Query Objects

Jason Dentler — Mon, 07 Sep 2009 20:17:50 GMT

Part 8 is about abstracting NHibernate. Catch up by reading Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, and Part 7.

Warning: This post will contain an extraordinary number of links. They will lead you to the opinions of very smart people™. Click them. Read them. Learn something new.

There is no one best practice. I know. I googled for it. It seems there are just as many patterns as there are anti-patterns. In fact, these days we’re not even clear which is which. There are differing opinions all over the place.

What are my options?

Repositories

Steve Bohlen uses the repository pattern.
José Romaniello uses repositories in his Chinook Media Manager sample on NHForge.org
Ayende loved repositories in 2006, but not anymore.

Data Access Objects:

Fabio Maulo uses DAOs with query objects.
Tuna Toksoz uses DAOs with FindBy methods

Query objects:

In early 2009, Ayende posted that he no longer likes repositories, and has switched to query objects which expose raw NHibernate ICriteria.

Udi Dahan also prefers query objects

One note about all of this: Repositories and DAOs can both be used with query objects or simple FindBy methods. Query objects can also be used on their own.

What’s the score?

The experts don’t agree, so use whatever you think will work best for your application and your team. By the way, if you’re not following all of these people on twitter, go follow them now.

If you’re looking for a good NHibernate repository sample, check out Your First NHibernate based application by Gabriel Schenker on the NHForge wiki, or José’s Chinook WPF app.

In this sample application, we’re going to use Data Access Objects. The pattern is simple and well known. This application is small and we won’t have many queries, so we’ll use DAOs with FindBy methods. In a large project, such as an ERP, I would use query objects.

Splitting the CRUD

CRUD stands for create, read/retrieve, update, and delete/destroy. which correspond to SQL INSERT, SELECT, UPDATE, and DELETE respectively.

Suppose we’re tracking down an issue in our system where the customer’s middle name was being erased from the database. You start with the most likely locations such as the round trip through the customer update view. No luck. You’ll have to dig in deeper.

We’re using constructor dependency injection throughout our application. Our DAO is defined by the interface IDAO<T>. If you saw some object with a dependency of IDAO<Customer>, you would assume that it performs some database action on customer, so it would be a candidate for deeper investigation. Of course, without diving in to the code, you wouldn’t know what it actually does to customer.

As it turns out 95% of the uses of IDAO<Customer> only display customer data. They don’t actually change anything. You just wasted a LOT of time digging through code that couldn’t possibly cause your bug.

Now suppose you had split your IDAO interface to allow more fine-grained dependencies. Instead of IDAO<T>, you now have ICreate<T>, IRead<T>, IUpdate<T>, and IDelete<T>. When searching for a bug like the one I described, you only need to search through classes with dependencies on IUpdate<Customer> and possibly ICreate<Customer>.

We’re tracking which entity instances are transient (new, not saved) and which ones are already persisted (saved to the database) by the ID property. If the ID is equal to Guid.Empty, the instance is transient. If the ID has any other value, it’s persistent. Since we know that handy bit of information, we don’t really need separate interfaces for create and update operations. We can combine them in to one called ISave<T>. We now have IRead<T>, ISave<T>, and IDelete<T>.

Even though we’ve split our interface up by operation, we’re still only going to have one DAO implementation. In the Ninject module, we’ll bind each of our three interfaces to the DAO implementation.

Every entity has the same basic CUD, but what about entity-specific queries? In these cases, we’ll create entity-specific interfaces such as IReadCustomer. This means you could have up to four IoC bindings for each entity.

Splitting the CRUD operations in to separate interfaces has one added benefit. In our case, we don’t want to allow certain (most) entities to be deleted. In these cases, your entity-specific DAO shouldn’t implement IDelete. For this reason, we won’t implement deletes in our generic base DAO.

Show me some code already!

We put our interfaces in the data namespace of the core project and our implementations in the data project.

Namespace Data

    Public Interface IRead(Of TEntity As Entity)

        Function GetByID(ByVal ID As Guid) As TEntity

    End Interface

End Namespace

Namespace Data

    Public Interface ISave(Of TEntity As Entity)

        Function Save(ByVal Entity As TEntity) As TEntity

    End Interface

End Namespace

Namespace Data

    Public Interface IDelete(Of TEntity As Entity)

        Sub Delete(ByVal Entity As TEntity)

    End Interface

End Namespace

Namespace Data

    Public Interface IReadStudent
        Inherits IRead(Of Student)

        Function FindByStudentID(ByVal StudentID As String) As Student
        Function FindByName(ByVal LikeFirstName As String, ByVal LikeLastName As String) As IEnumerable(Of Student)

    End Interface

End Namespace

Imports NHibernate

Public Class GenericDAOImpl(Of TEntity As Entity)
    Implements IRead(Of TEntity)
    Implements ISave(Of TEntity)

    Public Sub New(ByVal Session As ISession)
        m_session = Session
    End Sub

    Protected ReadOnly m_Session As ISession

    Public Function GetByID(ByVal ID As System.Guid) As TEntity Implements IRead(Of TEntity).GetByID
        If m_Session.Transaction Is Nothing Then
            Dim RetVal As TEntity
            Using Tran = m_Session.BeginTransaction
                RetVal = m_Session.Get(Of TEntity)(ID)
                Tran.Commit()
                Return RetVal
            End Using
        Else
            Return m_Session.Get(Of TEntity)(ID)
        End If
    End Function

    Public Function Save(ByVal Entity As TEntity) As TEntity Implements ISave(Of TEntity).Save
        If m_Session.Transaction Is Nothing Then
            Using Tran = m_Session.BeginTransaction
                m_Session.SaveOrUpdate(Entity)
                Tran.Commit()
            End Using
        Else
            m_Session.SaveOrUpdate(Entity)
        End If
        Return Entity
    End Function

End Class

Imports NHibernate
Imports NHibernate.Criterion

Public Class StudentDaoImpl
    Inherits GenericDAOImpl(Of Student)
    Implements IReadStudent

    Public Sub New(ByVal Session As ISession)
        MyBase.New(Session)
    End Sub

    Public Function FindByName(ByVal LikeFirstName As String, ByVal LikeLastName As String) As System.Collections.Generic.IEnumerable(Of Student) Implements IReadStudent.FindByName
        Dim crit As ICriteria = m_Session.CreateCriteria(Of Student) _
            .Add(Expression.Like("FirstName", LikeFirstName)) _
            .Add(Expression.Like("LastName", LikeLastName)) _
            .SetMaxResults(101)
        If m_Session.Transaction Is Nothing Then
            Using Tran = m_Session.BeginTransaction()
                Dim RetVal = crit.List.Cast(Of Student)()
                Tran.Commit()
                Return RetVal
            End Using
        Else
            Return crit.List.Cast(Of Student)()
        End If
    End Function

    Public Function FindByStudentID(ByVal StudentID As String) As Student Implements IReadStudent.FindByStudentID
        Dim Crit = m_Session.CreateCriteria(Of Student) _
            .Add(Expression.Eq("StudentID", StudentID))
        If m_Session.Transaction Is Nothing Then
            Using Tran = m_Session.BeginTransaction
                Dim RetVal = Crit.UniqueResult(Of Student)()
                Tran.Commit()
                Return RetVal
            End Using
        Else
            Return Crit.UniqueResult(Of Student)()
        End If
    End Function

End Class

using System;

namespace NStackExample.Data
{
    public interface IRead<TEntity> where TEntity : Entity 
    {

        TEntity GetById(Guid ID);

    }
}

namespace NStackExample.Data 
{
    public interface ISave<TEntity> where TEntity : Entity 
    {

        TEntity Save(TEntity entity);

    }
}

namespace NStackExample.Data
{
    public interface IDelete<TEntity> where TEntity:Entity 
    {

        void Delete(TEntity entity);

    }
}

using System.Collections.Generic;

namespace NStackExample.Data
{
    public interface IReadStudent : IRead<Student>
    {

        Student FindByStudentID(string StudentID);
        IEnumerable<Student> FindByName(string LikeFirstName, string LikeLastName);

    }
}

using NHibernate;

namespace NStackExample.Data
{

    public class GenericDAOImpl<TEntity> : IRead<TEntity>, ISave<TEntity> where TEntity : Entity
    {

        public GenericDAOImpl(ISession Session)
        {
            m_Session = Session;
        }

        protected readonly ISession m_Session;

        public TEntity GetByID(System.Guid ID)
        {
            if (m_Session.Transaction == null)
            {
                TEntity retval;
                using (var Tran = m_Session.BeginTransaction())
                {
                    retval = m_Session.Get<TEntity>(ID);
                    Tran.Commit();
                    return retval;
                }
            }
            else
            {
                return m_Session.Get<TEntity>(ID);
            }
        }

        public TEntity Save(TEntity Entity)
        {
            if (m_Session.Transaction == null)
            {
                using (var Tran = m_Session.BeginTransaction())
                {
                    m_Session.SaveOrUpdate(Entity);
                    Tran.Commit();
                }
            }
            else
            {
                m_Session.SaveOrUpdate(Entity);
            }
            return Entity;
        }

    }

}

using NHibernate;
using NHibernate.Criterion;
using System.Collections.Generic;
using System.Linq;

namespace NStackExample.Data
{
    public class StudentDAOImpl : GenericDAOImpl<Student>, IReadStudent
    {

        public StudentDAOImpl(ISession Session) : base(Session) { }

        public System.Collections.Generic.IEnumerable<Student> FindByName(string LikeFirstName, string LikeLastName)
        {
            ICriteria crit = m_Session.CreateCriteria<Student>()
                .Add(Expression.Like("FirstName", LikeFirstName))
                .Add(Expression.Like("LastName", LikeLastName))
                .SetMaxResults(101);
            if (m_Session.Transaction == null)
            {
                using (var Tran = m_Session.BeginTransaction())
                {
                    var RetVal = crit.List().Cast<Student>();
                    Tran.Commit();
                    return RetVal;
                }
            }
            else
            {
                return crit.List().Cast<Student>();
            }
        }

        public Student FindByStudentID(string StudentID)
        {
            var Crit = m_Session.CreateCriteria<Student>()
                .Add(Expression.Eq("StudentID", StudentID));
            if (m_Session.Transaction == null)
            {
                using (var Tran = m_Session.BeginTransaction())
                {
                    var RetVal = Crit.UniqueResult<Student>();
                    Tran.Commit();
                    return RetVal;
                }
            }
            else
            {
                return Crit.UniqueResult<Student>();
            }
        }


    }
}

Other changes

I’ve cleaned out the course and student DAO junk from part 7. These were just used to illustrate session-per-request.

The fluent mapping classes have been moved in to a mapping folder.

That’s it for part 8. Don’t forget to write your tests for the queries.

Jason
- IBlog.Post(Part8) operation completed. Executing IWatchTV.Watch(Timespan.FromHours(1))