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?
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