More on NCommon

Once again, I’m going to talk about NCommon.  I want to share some of Ritesh Rao’s posts on concepts that NCommon incorporates.  I’m very impressed with his architecture and it helps that he provides NCommon for NHibernate, Linq2Sql, Entity Framework (and I see he is venturing into EF v2).

My last post touched on this, but I’ll review it again:

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

NCommon uses the Apache License 2.0

NCommon uses the  Microsoft.Practices.ServiceLocation – this allows you to plug in your dependency inversion container of choice.  

I have gotten rid of the generic IoC wrapper implementation from the library as it doesn’t seem necessary anymore with the rally behind the Common Service Locator project.

This is shown in the accompany tests setup:

[SetUp]
        public void SetUp()
        {
            EFUnitOfWorkFactory.SetObjectContextProvider(() =>
            {
                var context = new TestModel();
                return context;
            });
            var locator = MockRepository.GenerateStub<IServiceLocator>();
            locator.Stub(x => x.GetInstance<IUnitOfWorkFactory>())
                   .Return(new EFUnitOfWorkFactory()).Repeat.Any();
            ServiceLocator.SetLocatorProvider(() => locator);
        }

NCommon sets the object context and implements the IUnitOfWorkFactory (the above shows with Entity Framework).

An example of how this is used can be found in the UnitOfWorkScopeTransaction class (UnitOfWorkScopeTransaction.cs- trunk/NCommon/src/Data)

ie. the ‘GetTransactionForScope’ method to retrieve the UnitOfWorkFactory:

var factory = ServiceLocator.Current.GetInstance<IUnitOfWorkFactory>();
var newTransaction = new UnitOfWorkScopeTransaction(factory, isolationLevel);
newTransaction.AttachScope(scope);
CurrentTransactions.Add(newTransaction);
return newTransaction;

The NCommon tests highlight the features of NCommon as well, including Fetching Strategies, Specification, Repositories, and Unit of Work.

Let’s look at some of Ritesh’s posts…

http://www.codeinsanity.com/2009/04/repository-pattern-thoughts.html

Some key items in this post to quote:

repositories should really represent a queryable data store that doesn’t abstract away queries behind methods that some unfortunate developer has to maintain and evolve, but rather allow consumers of the repository to query it directly. Hence why NCommon relies on repositories to implement the IQueryable interface to provide a query infrastructure directly on top of NCommon repositories.

I think this is an important piece to understand, and Ritesh follows up with the comment:

The approach I would take is rather than exposing the infrastructure requirements in the query object, I’d like it to take in an IQueryable and return back a IQueryable. This will allow chaining of queries by multiple of such Query objects without exposing any infrastructure concerns.

…

The problem with exposing ICriteria, or any other infrastructure component, to all layers of the application is that eventually a lot of infrastructure concern creeps into layers of the application where they don’t belong. I dislike the idea of having the expose ICriteria to the UI for adding paging and sorting on top of the query encapsulated by ICriteria.

That being said, in my opinion IQueryable is best suited for this job. Its a framework level member that is infrastructure agnostic, provides a very nice way to chain queries together and encapsulates our query requirements rather well.