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

  • 1
    What do you think of the answer rowanmiller gave? Seems perfectly reasonable to me. – Robert Harvey Mar 30 '16 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 – Loren.Dorez Mar 30 '16 at 15:13
  • see also lostechies.com/jimmybogard/2009/09/11/wither-the-repository where Bogard argues similarly. – mcknz Mar 30 '16 at 15:37
  • My take on why EF (and other ORMs) are not repositories. – Eric King Mar 30 '16 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. – Mr Cochese Dec 6 '16 at 11:32
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.

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.

  • 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? – Loren.Dorez Mar 30 '16 at 16:51
  • @Loren.Dorez: A Service Layer has Business Domain-Specific methods, like TransferFunds() and BuildWidget(). A Repository just contains CRUD methods. – Robert Harvey Mar 30 '16 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? – Loren.Dorez Mar 30 '16 at 17:04
  • The Service Layer might access the Repository, if you have one, instead of EF directly. – Robert Harvey Mar 30 '16 at 17:22
  • @RobertHarvey Can you show me an example using the Get Methds above? As now im a bit confused sorry. – Loren.Dorez Mar 30 '16 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/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.