9

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

Improve this question
5
  • 1
    What do you think of the answer rowanmiller gave? Seems perfectly reasonable to me. Commented Mar 30, 2016 at 15:10
  • @RobertHarvey Yes it was a good answer but i want to see how others feel about the topic before i make a decision to repository or not Commented Mar 30, 2016 at 15:13
  • see also lostechies.com/jimmybogard/2009/09/11/wither-the-repository where Bogard argues similarly. Commented Mar 30, 2016 at 15:37
  • My take on why EF (and other ORMs) are not repositories. Commented Mar 30, 2016 at 16:12
  • A repository wouldn't have method like GetWithIncludesABC. The repository pattern is an abstraction of, basically, a database table as a collection. Usually, it is possible to query the collection (e.g. by LINQ), and the repository then converts the query into SQL. What you're talking about sounds more like a Data Gateway. Commented Dec 6, 2016 at 11:32

3 Answers 3

Reset to default
12

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.

Improve this answer
1
4

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.

Improve this answer
8
  • How does Repository differ from a Service Layer aspect? from what I can find if im returning IQueryable then im essentially a Repository if im returning IEnumerable then im using a service layer. Is this correct? Are Service Layer and Repository Patterns Similar? Commented Mar 30, 2016 at 16:51
  • @Loren.Dorez: A Service Layer has Business Domain-Specific methods, like TransferFunds() and BuildWidget(). A Repository just contains CRUD methods. Commented Mar 30, 2016 at 16:53
  • So both a Service Layer and Repository would directly access the DBContext then? So you would put the CRUD in the Repo and Get Methods and other methods in the Service Layer? Am i understandig this correctly? Commented Mar 30, 2016 at 17:04
  • The Service Layer might access the Repository, if you have one, instead of EF directly. Commented Mar 30, 2016 at 17:22
  • @RobertHarvey Can you show me an example using the Get Methds above? As now im a bit confused sorry. Commented Mar 30, 2016 at 17:28
1

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/

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.