The NCommon codebase has been moved from CodePlex to Google Code. You can get this code here:
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