Patterns for using EntityFramework?

Question

What is alternative patterns of using for Entity Framework ?

Some I know are:

1. "Plain" EntityFramework - aka Unity of Work

   using (Data.Model c = new Data.Model())
   {
       var z = c.Users.Where(x=>x.Name=='John');
   }
   
   

2. Repository pattern

   //Model implements IRepository
   User user = Model.Instance.Get<User>(u => u.Name == "John");
   

3. What else ?
4. ?

Answer 1

A good book to look at is Martin Fowler's "Patterns of enterprise application architecture".

There he goes through some patterns for retrieving/mapping data like DTOs, Unit of work, repository pattern etc... Maybe something could be useful together with the Entity Framework. I'd have to take a look at it.

Answer 2

I answer your question based on the assumption that you are using Entity Framework directly in your UI/controller/Services.

It has been proven that using any ORM, inclusing EF, directly in your UI/Controllers/Services will cause a lot of problem in the future. On top of that, it makes it so hard, if not impossible, to unit test your application.

The second approach ie "Model implements repository" is also wrong in my opinion, becuase Model and Respositories have different responsiblities and based on "Single Responsibilty" part of SOLID principles you should not merge the two concepts together. Even if you want to use Active Objects pattern in your model, which I don't recommend, you must decouple your model from the ORM you use.

The best and the most recommended solution is to have an interface like IRepository or IRepository with the very basic members as the pattern suggests. something like:

Interface IRepository<T> where T:class
{
    void Insert(T entity);
    void Update(T entity);
    void Delete(T entity);

    // if you don't want to return IQueryable
    T FindById(object id);
    IEnumerable FindXXXXX(params)

    // if you prefer to return an IQueryable
    IQueryable<T> Find(Expression<Func<T, bool>> predeicate);
}

Note that some poeple beleive Repositories should not return IQueryable. Additionally, You can consider using ISpecification instead of expressions and lambda.

you would need to implement IRepositoy interface for most of your entities. Using this approach you can also mock your repositories when writing unit tests. In production, you would need to use an Ioc provider such as Unity, Ninject, Linfu, Catsle and etc. you can also benefit from microsoft's common service locator implementation to avoid coupling to a specifi IoC framework.

In the old days, I used to have a data access interface which was impleneted for a specific business domain or a service. One of the issues with this approach is that you would end up with duplicate code in different data access services if you keep track of your source code and you will eventually.

Answer 3

We use code similar to what you have in your unit of work example.

What we do in addition is to map objects to Data Transfer Objects.

Answer 4

There are many articles on the subject, but the list will be reduced substantially if you'd like a good one. This article from MSDN Magazine is pretty good, although it deals specifically with n-tier applications. But since you don't say what you're building, maybe it will help.

Answer 5

LINQ 2 SQL can be an alternative. Here is an article Dependency Injection with Unity and Linq to SQL DataContexts

UNITY - http://unity.codeplex.com/