NerdDinner MVC4 version - why did they delete the repository classes?

Question

I've been checking out the NerdDinner tutorials. I was reading through the original PDF tutorial (http://aspnetmvcbook.s3.amazonaws.com/aspnetmvc-nerdinner_v1.pdf) that uses LINQ to SQL and MVC2. In that tutorial, they implement a data context and then implement repository classes to interact with the data entities.

I saw the project was updated to use MVC4 and Entity Framework (http://nerddinner.codeplex.com) so I browsed through that code to see what changes they'd implemented. They changed the project to be code-first with separate model classes for each data entity. I was surprised to see that they got rid of the repositories completely.

I thought it was generally good practice to abstract communication with the database through the repository pattern... I know tutorials often make poor design choices for the sake of brevity, but I'm wondering why a tutorial that had already implemented repositories made the decision to omit them from this version.

Is there something in MVC4 or EF that makes repositories obsolete/redundant?

Answer 1

There is a long debate on whether it makes sense to wrap such advanced abstractions like the Entity Framework in repositories.

Historically, repositories were great. It was safe to have an extra layer of abstraction just to be able to switch between different data providers, plain old DataSets, files, linq, whatever.

However, many EF purists claim that EF is already an abstraction of the unit-of-work and repository with the data context being the unit of work and dbsets being repositories. They claim that the LINQ is the good enough abstraction of a query language and you don't need specific, restricted APIs.

Others say that this is not safe to assume that all possible providers are compatible in a sense that they provide consistent results for the same LINQ queries. Some providers could be limited and even refuse to evaluate specific queries. This - the people say - means that you still need an abstraction over EF so that you guarantee the same data contract for higher layers.

If someone decided to remove the repository layer from the example, this is possibly because of one of two reasons:

• someone realized that repositories just make the example more complicated and removed them for simplicity
• someone who is an EF purist would like to advocate the fact that "nothing shall stand above EF"

Personally, I like repositories and use them whenever possible.

Answer 2

With the increase of popularity of CQRS, the Repository pattern is kinda falling out of favour, with people like Jimmy Bogard making good cases against its use.

Basically, it's easy for a Repository to end up as a large class which knows how to form lots of different queries, violating SRP. Avoiding this in a complex system can end up giving you lots of Repositories, and using a Repository in a simple system is just over-engineering.