title: What alternatives are there for Repository Pattern and UOW with EF 5 and above
body: <p>I know this is very close to opinionated question which is not tolerated in <code>SO</code> 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.</p>
  
  <p>I'm an <code>Entity Framework</code> enthusiast. Was introduced to <code>.NET</code> technologies about an year ago, when, <code>DbContext</code> and <code>DbSet</code> were already part of the <code>Entity Framework</code> so the discussion was already there, and I've read a lot about how the context is our generic repository and how the <code>DbSet</code> 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 <code>OR/Ms</code>.</p>
  
  <p>Well, it's probably true, but yet there are many articles about Repository pattern, do we really need it, what <code>Entity Framework</code> has become and so on, so I made the next step - if <code>Repository pattern</code> and <code>UOW</code> are not what used to be combined with the new versions of <code>EF</code> (5+) then what is the modern approach, what other options are now available to us to make better use of what <code>Entity Framework</code> 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 <code>EF</code> now so this is the main reason to finally write a question here.</p>
  
  <p>What I really like about <code>Repository pattern</code> 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:</p>
  
  <pre><code>using (var context = new MyDbContext())
  {
      Product prod = new Product();
      prod.Name = "Something";
      prod.Price = 10;
  
      context.Products.Add(prod);
      context.SaveChanges();
  }
  </code></pre>
  
  <p>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 <code>Repository pattern</code> - it allows us to keep it DRY and that's always nice.</p>
  
  <p>The second thing that I've always appreciated while using <code>Repository pattern</code> 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 : <code>GetAllDataForUsersWithMoreThanTenPurchasesPerMonth()</code> 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.</p>
  
  <p>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.</p>