Is there a reason for using the Repository pattern with Entity Framework if I know I will only ever use EF?

Question

From reading various books and articles, I seem to rather often find the usage of the Repository-pattern suggested. I get the point if you need to be able to swap out your d

Answer 1

I think you're on the right direction. I asked myself the same question two years ago after I've used the repository pattern in some projects. I came to the conclusion that hiding your ORM behind a repository implemented on top of your ORM will get you nothing but unnecessary work. In addition to implementing meaningless FindAll, Find, Add ... methods you would loose some performance optimization possibilities that the ORM gives you. Or at least it will get quite hard to apply some of those methods.

So if you're not going to switch your ORM within the lifetime of your project, I don't see any benefits in applying the repository pattern.

So instead of preparing for the situation where one could in future easily switch the ORM, I would suggest to do some more investigation upfront, wisely choose an ORM, stick with it and stay away from the repository pattern.

Answer 2

What people don't realize is that EF is already an Repository and Unit-of-Work.

Repository has become an anti-pattern because the criteria of its usage was never met in the first place. Never use a design pattern because its cool or trendy or trying to build your resume, in fact this should be a standard rule for all design patterns.

Only build a Repository and Unit-of-Work on top of EF if your application is

• very large (lasagna layer)
• long-lived (10 years or so)
• has more than 5 developers working in parallel
• has developers that are separated geographically
• requires a lot of maintenance
• multiple data access infrastructures

A good indication is when upgrading from EF5 to EF6 requires you to knock on everybody's door.

Answer 3

They are many opinions on the issue but after using repositories for 2 projects, i never tried it again.

Too much pain with hundreds of methods for all those cases with no clear benefits (i'm almost never going to swap out EF for another ORM).

The best advice would be to try it out so you can make an informed opinion on which route to take.

Some opinions against it here

Answer 4

I am actually in disagreement that EF is a correct example of a "Repository Pattern". It is a typed Data Access Layer and an exposed LINQ implementation.

Please note that if one fully endorses EF as "the business domain" then the above does not hold; however, I use EF - as poorly as it does - with Schema First, in which EF is not the strict business domain. The term "correct" is used to reinforce this viewpoint - adjust for your own perspective / design.

A correct Repository Pattern, in my book, exposes aggregate roots of relevant operations. That is, the implementation details (EF) is kept within the Repository, as much as possible. That is, the Repository takes care of the mapping of the relevant Domain objects to the underlying model.

This is an agreement with how Microsoft defines The Repository Pattern - note that the business entities are mapped to a data source. (And thus my fundamental disagreement with EF fulfilling this role: EF only has a chance of sanely maps business entities when designed from Code First.)

The best summation / article I have found is Repository pattern, done right by Gauffin. While he approaches the Repository pattern from a more extreme view than I, here are some key points as to why EF's simply bleeds through an Active Record / ORM pattern.

Here are some selected excerpts that highlight why I do not thing that EF is a proper implementation of a Repository Pattern.

The repository pattern is an abstraction. It’s purpose is to reduce complexity and make the rest of the code persistent ignorant. As a bonus it allows you to write unit tests instead of integration tests. The problem is that many developers fail to understand the patterns purpose - and create repositories [ie. EF] which leak persistence specific information up to the caller

..

Using repositories is not about being able to switch persistence technology (i.e. changing database or using a web service etc instead) .. Repository pattern do allow you to do that, but it’s not the main purpose.

..

When people talks about Repository pattern and unit tests they are not saying that the pattern allows you to use unit tests for the data access layer .. If you use ORM/LINQ in your business logic you can never be sure why the tests fail.

..

Do note that the repository pattern is only useful if you have POCOs which are mapped using code first. Otherwise you’ll just break the abstraction using the entities. [That is, only EF Code First can even attempt to meet this requirement.]

..

Building a correct repository implementation is very easy. In fact, you only have to follow a single rule: Do not add anything into the repository class until the very moment that you need it

And if you do use EF as a Repository - I believe it's still a typed DAL, as much as it bleeds - please do not try to hide it in a "more generic" pattern - a Repository pattern is not about type unification, it is about exposing aggregate roots for a particular context and operations on such.

See What specific issue does the repository pattern solve? as well.

---

While I speek against EF being a correct Repository Pattern - it is the Active Record pattern - I am not a Repository purist. That is there are cases when I will bleed EF (or L2S) entities in specific cases; I accept this as technical debt. Just understand the cost of breaking such a Repository / Domain boundary.

Answer 5

I'm not as hot on the repository pattern as I used to be, but I still find it can be useful in the following scenarios (assuming swapping the ORM isn't one of them):

• Unit testing (assuming you'd rather mock or stub than use Sqlite or hit a real db)
• Being able to stub out data access during development via a repository that has an in-memory IEnumerable as its backing source.