Entity framework 6 providing repositories and UoW out of the box

Question

But how do you use it?

I have a Code First project set up, and trying out some stuff with this new EF6. Reading all kinds of posts/blogs from at least 2 years old about EF4/5. But nothing whatsoever about EF6.

Let's say I have these entities:

public DbSet<Person> Persons { get; set; }
public DbSet<Order> Orders { get; set; }
public DbSet<Invoice> Invoices { get; set; }

Do I still need to create repositories for each entity? Or would a class suffice with some methods to do some custom calculations aside from CRUD?

I know that this line:

kernel.Bind<MyDbContext>().ToSelf().InRequestScope();

Would suffice for DI, and that it will inject via constructor to upper layer classes where applicable.

The project has a class library and a web project asp.net-mvc. Where the class lib project contains my entities and has Migrations enabled.

Any light on this matter is really appreciated.

Answer 1

I've added a Repository layer on top of EF (which utilizes both Repository and UoW patterns inherently in its construction) in a couple of projects, and I've done that with one class that utilizes generics so that I only needed one file for all of my entities. You can decide if you want to do it or not, but I've found it useful in my projects.

My repositories have typically started out like what I've shown below, following up with more extension methods if/when I come across a need for them (obviously I'm not showing all of them, that's up for you to decide how to implement your repository).

public class Repository<T> : IRepository<T> where T : class
{
    protected IDbContext Context;
    protected DbSet<T> DbSet { get { return Context.Set<T>(); } }

    public Repository(IDbContext context = null)
    {
        Context = context ?? new DbContext();
    }

    public void Add(T newRecord)
    {
        DbSet.Add(newRecord);
    }

    public void Update(T record)
    {
        var entry = Context.Entry(record);
        DbSet.Attach(record);
        entry.State = EntityState.Modified;
    }

    public void Remove(T record)
    {
        Context.Entry(record).State = EntityState.Deleted;
        DbSet.Remove(record);
    }

    public IQueryable<T> Where(Expression<Func<T, bool>> predicate)
    {
        return DbSet.Where(predicate);
    }

    public bool Contains(Expression<Func<T, bool>> predicate)
    {
        return DbSet.Count(predicate) > 0;
    }

    public int Count(Expression<Func<T, bool>> predicate)
    {
        return DbSet.Count(predicate);
    }

    public int Save()
    {
        return Context.SaveChanges();
    }
}

I've used repositories for 2 main reasons:

1. Unit testing. Doing this pattern allows me to fake the underlying data without having to have bad data in my database. All I need to do is simply create another implementation of IRepository that uses an in-memory list as its data source, and I'm all set for my pages to query that repository.

2. Extensibility. A fair number of times I've put in some methods into my repository because I found myself constantly doing the same logic with queries in my controllers. This has been extremely useful, especially since your client-side code doesn't need to know how it's doing it, just that it is doing it (which will make it easier if you need to change the logic of one file vs. multiple files).

This not all of it, obviously, but that should be enough for this answer. If you want to know more on this topic, I did write a blog post on it that you can find here.

Good luck on whatever you decide to do.

Answer 2

Entity Framework in itself can be considered a Repository. It facilitates work with data, in this case a database. This is all that a Repository does.

If you want to build another Repository on top of what EF provides, it is completely up to you - or to your business rules.

Many complex projects uses 2-3 layers of repositories with web services between. The performance is lower but you gain on other plans like security, resilience, separation of concerts, etc.

Your company might decide that it's in their best interest to never access data directly from front-end projects. They might force you to build a separate web-service project, which will be accessible only from localhost. So you will end up having EF as Repository in the webservice project. On the front-end side you will obviously need to build another Repository which will work with the web-service.

It also depends a lot of your project. If it's a small project it really it's overkill to build a second Repository on top of EF. But then again, read above. Nowadays security matters a lot more than performance.

To be politically correct I'm including the comment made by Wiktor Zychla:
"DbSet is a repository and DbContext is a Unit of Work. "Entity Framework is a Repository" could lead to unnecessary confusion."