Entity Framework itself implements unit of work pattern in form of the ObjectContext class. That’s fine but it has the following main disadvantages:
a) if you will use it from your business layer then you will be very tightly connected to the concrete DB layer implementation (in this case Entity Framework)
b) it will be much harder or impossible to do TDD.
It’s good practice to wrap the data access logic using Repository pattern. In other words it’s good to use the Repository pattern in order to abstract out/decouple the business layer from the data access layer. Fine, there is one Repository patter definition but many implementers and you can implement it also by your own. The basic idea is the same but many slightly different implementations.
When you work on different projects developed by the different people it’s good to establish enterprise-wide implementation of any common patterns/areas. Additionaly, it would be better if ti would be world-wide known implementation. So that’s NCommon which you can find on ncommon.codeplex.com.
NCommon provides, we could say, abstraction of the common programming areas like Repository, UnitOfWork, Guards, States, etc. In this entry I’ll focus on Repository.
NCommon provides the abstract Repository implementation – independent from any specific/concrete DB access implementation PLUS it contains implementations for Entity Framework, NHibernate, Db4O, etc. All specific implementations are located in its own projects. The advantage is that you can use out of the box implementation of your favorite implementation.
In addition, the base abstract Repository class offers LINQ provider on Class Level, not property level. Honestly, I like it ;o). Here is a sample:
using (var scope = new UnitOfWorkScope())
var savedCustomer = new EFRepository<Customer>()
.First(x => x.CustomerID == customer.CustomerID);
In addition the base NCommon Repository classes are tightly connected with UnitOfWork pattern which is also abstracted into NCommon in form of UnitOfWork classes. You can get it also out of the box together with the different DB access specific implementations!
The unit of work implementation IS NOT ONLY 1 CONNECTION specific but spreads over different repositories and over different DB connections (if it’s your case). In other words, you can have i.e. a users repository implemented by NHibernate and connecting to UsersDB and OrdersRepostory implemented via EntiryFramework connecting to OrdersDB and the following example works:
In other words, one connection transaction will be elevated to the distributed transaction transparently and automatically. I like it! It seems to me really robust.
ALL is supported by standard service locators implemented by Microsoft Patterns and Practices team and with the NUnit tests!
I think, NCommon is really cool set of classes which collects the common aspects you will face while development. It’s really worth studying it! Here is a list of the links you can use:
Anyway, cool way how to check the latest library description is to look at the unit tests from GitHub.
Happy common coding !