Repository + UnitOfWork pattern for entity framework

Question

I was searching the net up and down and I didn't manage to find a suitable design for my application.
I am looking for Repository+UnitOfWork pattern that will manage connections and dispose them automatically when done.

I need to support both web application where each request will have its own UnitOfWork and windows application where each thread will have its own UnitOfWork. I need the patters to dispose automatically the UnitOfWork whrn request/thread is done. I also would like to support rolback in case of exception.

Right now I use StructureMap so I don't care to continue use it in the suggest answers.

The reason I need Repository pattern is to achieve all the abilities I need to all my entities. The reason I need UnitOfWork is to allow changes in more then one entity.

I will really appriciate any help.

Thanks.

Answer 1

I used this blog as a really good starting point:

http://www.primaryobjects.com/CMS/Article122.aspx

It starts at the VERY beginning, and provides source code at the end for you. It also uses StructureMap, so it might be somewhat familiar to you.

Answer 2

I would recommend the NCommon framework. You can find a blog about it here: http://www.codeinsanity.com/

Answer 3

I wrote an article last year about writing LINQ enabled repositories that can be faked easily for unit testing and works well with dependency injection. Here is the article . In short the article describes a unit of work that mimics the LINQ to SQL DataContext and wraps an IDataMapper interface that abstracts the actual O/RM tool. The unit of work contains properties of type Repository<TEntity> such as Repository<Customer> or Repository<Order> and the repository class implements IQueryable<T> , which allows you to LINQ over it.

The IDataMapper is a simple interface that looks like this:

public interface IDataMapper : IDisposable
{
    Repository<T> GetRepository<T>() where T : class;

    void Save();
}

The solution described in the article is designed to be unit test friendly and DI friendly. In fact, the only configuration you need is the following:

string northwindConnection = GetConStr("Northwind");

container.RegisterSingle<IUnitOfWorkFactory<NorthwindUnitOfWork>>(
    new LinqToSqlNorthwindUnitOfWorkFactory(northwindConnection));

container.RegisterSingle<IUnitOfWorkFactory<SalesUnitOfWork>>(
    new EntityFrameworkSalesUnitOfWorkFactory());

Answer 4

If you already have unit of work and repositories and you are using StructureMap so where is the problem?

You can simply configure your classes as:

ObjectFactory.Configure(x => x.For<IUnitOfWork>()
                              .HybridHttpOrThreadLocalScoped()
                              .Use<EFUnitOfWork>());

And you can use dependency injection to pass unit of work to repositories.