Using NCommon – Unit Of Work, Repository, etc…

 

***Update***

The NCommon codebase has been moved from CodePlex to Google Code.  You can get this code here:

http://code.google.com/p/ncommon/

Any links below have not been updated

—-

I was looking for a good repository for using Entity Framework in a proof of concept project.  I stumbled upon a project called ‘NCommon’.   The beauty of this framework is that is appears to support Entity Framework, Linq to Sql, and NHibernate.

The basis of NCommon is that it helps build a ‘domain driven’ architecture.  A summary from the link above describes the major parts of NCommon:

NCommon is a library that contains implementations of commonly used design patterns when developing applications. So far NCommon provides the following:

• Framework for implementing a Unit of Work Pattern
• Framework for implementing a Repository pattern that utilizes Linq
• Framework for implementing a Validations and Business Rules
• Implementation of the Specification pattern using Expressions
• Utility class to help store application specific data in the Thread Local Storage / Current Web Request and AppDomain Level Storage
• A Guard class that mimics common guard statements that verify parameter values and throws exceptions if values are not acceptable.

NCommon includes a sample website – done with asp.net mvc.  I setup a ‘test’ (it’s not really a test, more of a ‘ok, looks good, how does it work’)

My sample snippet is a call to retrieve and address entity and update it’s state:

Step one:  Register the Unit of Work and Repository with your IOC container of choice – in this case I use Castle Windsor, you can use any IOC however, since NCommon uses the Microsoft ServiceLocator.  (Here is an example done in Unity)

Since I have chosen to try Entity Framework, I’m registering the ‘EFUnitOfWorkFactory’ and the ‘EFRepository’ – again, you could use Linq2Sql or NHibernate here.  The unit of work factory is, of course, in charge of creating the unit of work  🙂

Step Two:  This is some underlying plumbing that occurs, I’m telling the ServiceLocator what IOC container I’m using for NCommon, additionally, I’m telling the EFUnitOfWorkFactory what EF DataContext I’m using (‘BistroEntities’ is my ObjectContext for my EF test project):

I’ll show in a bit what happens at a asp.net mvc level, but this is the core ‘setup’ involved – this is done once in your application, after that you never look at it again   🙂

Now, let’s show how I can use this ‘unit of work’ with a ‘repository’ pattern:

First off, I want to define in the code that I’m beginning a unit of work.  Martin Fowler tells us all about ‘Unit of Work’ :

Maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems.

Obviously we want this in our application !  ( I should say you ‘need’ this – lol)

In my senario above, I’m only making one ‘save’ call, however, I could have a situation where I’m saving a collection of entities – the address, a company update, an employee update, a audit trail save, etc… This is all accomplished through the UnitOfWorkScope – it is handling the underlying Transaction as well.  The UnitOfWorkScope does a lookup to the ServiceLocator to find the corresponding type of unit of work.

Secondly, I’m instantiating a new EFRepository.  In the asp.net mvc sample, you’ll see this will be associated to a controller by using dependency injection.  It would look something like this:

public AddressController : Controller
{
       private readonly EFRepository<Address> _addressRepository
       public AddressController(EFRepository<Address> addressRepository)
       {
              _addressRepository = addressRepository;
…

(Basically, the container handles the instantiation of the repository on your behalf via dependency injection)

The entity is retrieved, updated, and saved.

Notice the Unit of work ‘Save’ call:  This save call is committing the underlying transaction.  If I left this out…the save wouldn’t occur  🙂

So, how does this work in the NCommon sample website code?

Obviously the real question is, ‘how do we set this up to use in our application’:

In the asp.net mvc application you must set it up in the global.cs file – where the application starts basically: (note, the NCommon sample code uses NHibernate):

I’ll skip over the NHibernate specific parts here, you can download the sample, the key item here is telling the Store about the NHibernate ISession (for EF/Linq2Sql this is ‘similiar’ to your context object):

The next section is the registration (again, see the sample code)

As with above, you can see the registration of the NHUnitOfWorkFactory and the NHRepository.

These get registered along with the controller registration that asp.net mvc offers as well as the ServiceLocator registration of our container.

Lastly then we move to the controller itself, again, looking at the NCommon sample web application:

Since the controller is registered, and the IRepository is registered, this is ‘autowired’ to find in the container the IRepository instance and create it on your behalf.

Lastly, we use it:

I think this is a fantastic setup and architecture – I would probably insert a ‘service layer’ in between my controller and my repository however.  (and if you have seen my other posts, I think something like RIA.NET – which I think should be called ‘DomainServices.NET’ comes into play…eventually…)

Thanks to Ritesh Rao for his NCommon library as well as for his help in getting starting with NCommon