Repository and Unit of Work Patterns with Entity Framework

I'm sure just about every new ASP.NET MVC developer stumbles upon this tutorial on the ASP.NET site written all the way back in 2013: Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application. I did, myself, when I was first getting started. I cannot say how much I wish Microsoft would remove this tutorial, as it does a huge disservice to the community by encouraging new developers to chart a pointlessly disasterous course.

Why do I say that? Well, just look at some of the methods in the GenericRepository class the tutorial lays out. Here's the definition for GetById:

public virtual TEntity GetByID(object id)
{
    return dbSet.Find(id);
}

And then look at Insert:

public virtual void Insert(TEntity entity)
{
    dbSet.Add(entity);
}

Some of the other methods are slightly more complex, but still amount to merely proxying a call from the repository to a nearly identical call in Entity Framework. Why is that the case? Well, because ORMs like Entity Framework already implement the Unit of Work and Repository patterns. Specifically with Entity Framework, the DbContext is the Unit of Work and each DbSet is a respository.

People tend to follow patterns without thinking about the reason for those patterns. A pattern, in general, is merely a codified way of solving a problem. It's therefore only useful if you need to solve the same problem its meant to solve. What is that problem in the case of the Unit of Work/Repository patterns? Dealing with SQL. Back before ORMs were popularized, working with a database was done pretty much manually. The developer would open a connection to the database, construct SQL statements to send to it, parse the results, etc. If the developer wasn't particularly concerned with order, and unfortunately most weren't, then you were left with a mess of spaghetti-code, with vast quanties of string containing bits of SQL intersperse all over the place. The repository pattern was a way of shuffling all of this SQL away into a single place where it could be reused and wouldn't clutter up the main application code. The unit of work pattern was a way of orchestrating the various work being done by the repositories so you could do things like transactions to rollback changes when there were issues.

And, you know what? Entity Framework does all that. As a result, the problem doesn't exist, and the patterns used to solve the problem aren't necessary. That Microsoft implicitly recommends using these patterns anyways, is just bad guidance and a true disservice. Granted, code samples they've created since the release of EF 6 have backed away from the repository approach, so it seems they've internally realized it's not appropriate. However, that's all the more reason to dump this part of the tutorial entirely. It's outdated, sure, but the average newbie isn't going to pay attention to that. As long as it's out there to be consumed, consumed it will be, and countless more new developers will proceed down a path that will ultimately only bring them pain and add to the complexity and maintenance of their applications.

UPDATE 06/01/2016

Want to see a better way? I finally have the first set of articles online dealing with generics, which includes creating a truly generic repository.

comments powered by Disqus