What alternatives are there for Repository Pattern and UOW with EF 5 and above

Question

I know this is very close to opinionated question which is not tolerated in SO so I want to make it clear - I'm not asking what is the best alternative to Repository Pattern + UOW but what one could use instead.

I'm an Entity Framework enthusiast. Was introduced to .NET technologies about an year ago, when, DbContext and DbSet were already part of the Entity Framework so the discussion was already there, and I've read a lot about how the context is our generic repository and how the DbSet is our UOW and that nowadays if you have to consider using some sort of further abstraction it mostly benefits the ability to perform test and to ease the switching between different OR/Ms.

Well, it's probably true, but yet there are many articles about Repository pattern, do we really need it, what Entity Framework has become and so on, so I made the next step - if Repository pattern and UOW are not what used to be combined with the new versions of EF (5+) then what is the modern approach, what other options are now available to us to make better use of what Entity Framework offers out of the box? So, the problem is that literally I ended up with nothing in particular. Nothing remotely close to a tutorial or even a well described idea on how it is supposed to use EF now so this is the main reason to finally write a question here.

What I really like about Repository pattern and the way it works is the ability to keep things separated. By which I mean that I have seen people writing literally in every method that need say DB access something like:

using (var context = new MyDbContext())
{
    Product prod = new Product();
    prod.Name = "Something";
    prod.Price = 10;

    context.Products.Add(prod);
    context.SaveChanges();
}

Obviously there is code that is repeated across the entire application and it seems natural to separate this in it's own method, project... Data Access Layer ... So this is the first thing that I find good about Repository pattern - it allows us to keep it DRY and that's always nice.

The second thing that I've always appreciated while using Repository pattern is when it comes to more specific queries that retrieve information that you should use from multiple methods. So for example if I need some method like : GetAllDataForUsersWithMoreThanTenPurchasesPerMonth() and having a repository it's pretty easy to write this method once and then just call it wherever it's needed, not to mention how much easier the maintenance is if you need to change something in this method and the business logic is only on one place and you don't have to go to each method and rewrite this specific piece of code.

So maybe there's much more that could be written about this but, that's something I have noticed in all application I've been working on so I'm really interested. What are the modern approaches? I'm talking mostly about small to medium applications.

Answer 1

• There are dozens of variations around Repository + EF out there, so it's hard to tell what you're referring to as Repository Pattern + UOW. Maybe you could post one of your own Repositories so we can make suggestions ?

• Many "no-repository" rants that have sprouted recently are really rants against Repository pattern misusage. Maybe the masses have been widely misusing it recently, that's why these people want to ban it - but they're wrong. There's nothing bad about Repository if you stick to what it was meant for originally - an object that seems like an in-memory collection to query from or add to, but maps to another layer under the covers. Understanding each pattern separately also helps. Repository != Unit of Work, and some repo implementations might not use a UoW at all.

• If your code sample is supposed to show things that we could reuse in a base Repository implementation, it's probably a bad example and a bad idea. You don't want to force the scope of your Unit of Work into the limits of a single Add() or Delete() repository call. You want a higher-level, execution context-aware object to control the business transaction and thus the Unit of Work. It's not up to the Repo to decide if and when things are going to be flushed to the DB.