In this post I will try to explain why the Repository Pattern is not redundant when we use an ORM like Entity Framework in our application.

There are many blog posts and many questions/answers in places like StackOverflow where developers argue about that issue.

I will not be writing code in this article but I will try to explain why Entity Framework does not implement the Repository Pattern and what is the difference between them.

Before reading this post by all means do have a look at this post of mine where I explain the Repository Pattern in detail.

Let me say a few words first about Entity Framework first. Entity Framework is an ORM.

The .Net framework provides support for Object Relational Mapping through EF.

So EF is a an ORM tool and it is now the main data access technology that microsoft works on.

Through EF we have many things out of the box provided for us. We have the automatic generation of SQL code.

It maps relational data to strongly typed objects. All the changes made to the objects in the memory are persisted in a transactional way back to the data store. 

In a nutshell it bridges the relational with the object oriented world.

A lot of developers like it because they do not want to learn SQL or deal with low level database specification details. As with all things there is a learning curve and a lot of developers use EF code in many layers in their application making the code non-testable an non-maintenable.

The Repository Pattern abstracts and encapsulates anything that has to do with persistence.

We can use Linq to Entities or stored procedures to store data in a data store that can be a file, a document db, a  cloud storage or a relational database. The rest of the application does not know that, as the Repository encapsulates everything storage related.

At this point I want to underline the fact that many developers confuse the domain objects with persistence objects like an EF entity.

The domain model models the behavior of the application. The domain objects describe fully the application and what it is supposed to do.

The persistence model models how and what data will be stored, so in essence it models storage structure.

Having all these in mind let's move to the argument that many developers put forward "that there is no need to use the Repository Pattern when we are using Entity Framework which implements the Repository Pattern, hence the Repository Pattern is redundant".

Entity Framework main objects are DbSet and DbContext. 

DbSets represent objects in memory. There are methods for adding, removing, getting objects. So one could say that DbSet looks like a repository.

The DbContext has methods for storing the data. So one could argue that DbContext implements UnitOfWork pattern.

One main benefits of the repository pattern is that there is no duplicate query logic and a separation of concerns. 

All of your queries for data when using Entity Framework are written against DbSet.

For example, when we are querying against a Customer or a Doctor entity, those entities are exposed on our DbContext as a DbSet.

DbSet implements the IQueryable interface. 

public class DbSet<TEntity> : DbQuery<TEntity>, IDbSet<TEntity>, 
	IQueryable<TEntity>, IEnumerable<TEntity>, IQueryable, IEnumerable
where TEntity : class

All LINQ extension methods implemented on DbSet,  return IQueryable. 

That means we will have queries like the one below(if we are implementing a book e-shop in ASP.Net MVC)

context.Books

.Where(b=>b.BookID==bookid)

.Select(b=>b.name)

.Include(a=>a.Author)

.ToList();

in all layers of the application. We will have queries like the one above in our controller or service layer.

That is a leaky abstraction. UI or service layer should not know about how to implement data store persistence logic or have Linq to Entities.

So we violate both the seperation of concerns and the duplication of query logic.

Another benefit of the repository pattern is that it decouples your application or domain entities from persistence frameworks.

In our applications when using EF we use DbContext directly in our application, our application is tightly coupled to Entity Framework. So our application is tightly coupled with the persistence framework. Repository pattern definetely help us to achieve persistence abstraction. So EF looks like implementing the Repository pattern but we do not get the benefits we do from the correct use of the Repository Pattern.

Some people say that I wil use EF and I am not going to change to nHibernate or any other ORM. Well maybe EF in 4-5 years from now has a different implementation of DbContext and DbSet. What will happen if you want to update the code? Many changes should take place inside the code. You will have to change code all over the place. That will take time and it will result in breaking the code most definetely.

Bottom line is that we need to hide DbContext behind a repository and only use the repository interfaces in our application. The repository is a software design pattern that helps us abstract all storage related details from the rest of the application, help us architect the application in layered fashion. Entity Framework abstracts access to an relational database e.g SQL Server. Basically EF is an implementation detail of the Repository.

Hope it helps!!!