I posted a question on github to the EF Team. I got a reply saying it would be better to ask this question here so I will copy and paste it here as we as a link so other can see the few replies on GitHub.
Question: I was doing some research and someone pointed out that Line 24 of the DBContext Class states
DbContext is a combination of the Unit Of Work and Repository patterns.
Does this mean that we no longer need to abstract EF to a Repository and then use and Interface to inject it into Controllers?
Original post on Github: https://github.com/aspnet/EntityFramework/issues/4899
The reason I ask this is I seem to get into a spot where im adding a lot of methods to the repository like GetById, GetByName, GetWithIncludesABC, GetWithIncludes123, etc.. and it seems to be dirtying the repo in my mind
5
If you’re adding methods to a repository like
GetById
GetByName
GetWithIncludesABC
GetWithIncludes123
Then you’re better off moving to a Service Layer, and letting the Service Layer use EF directly. EF already has functionality similar to the above methods that you’re just endlessly duplicating.
A Service Layer exposes Business Domain methods, and uses CRUD to implement them. For example, you might have a method called TransferMoney(A, B), where A and B are checking accounts. This allows you to speak the language of your business domain, while the Service Layer handles the CRUD for you.
The only compelling reason I can think of where you might want to have a separate Repository Layer is so that you can mock that repository layer or substitute a different data source for testing purposes.
1
Robert Harvey said in his answer:
The only compelling reason I can think of where you might want to have a separate Repository Layer is so that you can mock that repository layer or substitute a different data source for testing purposes.
This is precisely why the Repository Pattern is still relevant. I also disagree with the Entity Framework teams’ assertion that they implement the Repository Pattern. Entity Framework is still very much tied to a database. The whole purpose of the Repository Pattern is to decouple and abstract away the exact persistence mechanism used in your application, so that nothing from the implementation of data access leaks outside of the repository layer.
If you are using the EF query API outside of the “repository,” like in a service object of some sort, I would say you are breaking the pattern.
Now, if it’s not a catastrophic problem for database like functionality to leak into your other code, and you can guarantee that you won’t need to move some of your CRUD operations to a web service in the future, then using EF directly would be OK.
Basically, Entity Framework takes the place of the Gateway object in the Repository Pattern. I don’t view it as a repository itself.
8
Repositories seem not needed – Microsoft in their sample backend microservices applications don’t use them:
https://github.com/Microsoft/BikeSharing360_BackendServices
The sample BikeSharing app was shown on Connect(); event (I think it can be used as a template for API projects):
https://blogs.msdn.microsoft.com/visualstudio/2016/12/14/connectdemos-2016-bikesharing360-on-github/