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 data layer from one to another, but my question is, if I know with 100% certainty that I will not use any other tech for data access, is there any reason for using said pattern?

The thing that I find myself doubting the most is that I don't really see what this extra layer of abstraction can bring to the table in this scenario. From my experience, EF with its fluent linq-to-entities -functionality should be more than enough for pretty much all my needs.

The most usual cases seem to start the repositories with methods such as FindAll, Find, Add and Delete, all of which are very easily accessible directly through EF (so no code duplication to speak of).

So am I just missing some big point, or is the repository more for when you need to support multiple different data access technologies?

Answer 1

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 2

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.