2

In the sense of application layers, I have a hard time figuring out, how to place Entity Frameworks DbContext. It seems to me that it aims to replace the repository layer, but on the other hand it doesn't really work like a more basic repository, which is implemented via an interface, making it easy to swap later.

So I found a lot of good posts on the service and repository layer (e.g. this post), but it doesn't seem to answer where Entity Framework fits in this pattern.

Should I add a repository layer on top of Entity Framework or should I just use DbContext in place of a repository, in my services?

Jakob Busk Sørensen
  • 5,599
  • 7
  • 44
  • 96
  • 2
    this is a good read: https://blog.zhaytam.com/2019/03/14/generic-repository-pattern-csharp/ – jazb Dec 04 '19 at 08:09
  • 1
    and a counter argument here: https://www.thereformedprogrammer.net/is-the-repository-pattern-useful-with-entity-framework-core/ – jazb Dec 04 '19 at 08:09
  • @Jazb In understand the counter arguments, but i feel like Repositories still add value in the sense that you don't need to repeat yourself. without the repositories, you'll find yourself dealing with id's all the time, and repeating the savechanges(), etc... a repository can simply replace that will a single method. – Glenn van Acker Dec 04 '19 at 08:15
  • @GlennvanAcker -yeah not right or wrong - just opinions and preferences – jazb Dec 04 '19 at 08:18
  • EF is both Repository and UoW. Check more details [here](https://stackoverflow.com/a/51781877/5779732). – Amit Joshi Dec 04 '19 at 09:02

2 Answers2

4

You need to ask yourself why would you want to abstract away your data-access layer.

The answer would typically be:

  • Unit Testing
  • Replacing the layer with another DB / persistence technology

Many are arguing that the 2nd argument is utterly false because:

  • Replacing that layer would usually have a much wider effect on your application than just configuring another implementation
  • It rarely happens and doesn't worth the effort

All in all, I tend to agree that testability should be your main concern and in the case of EntityFramework you can:

  • Use EF Core with its built-in InMemory provider
  • Use EF 6 and mock all the methods and DbSets in your context (by marking them as virtual).

And, to answer your question title: Yes. DbContext is already acting as a repository.

haim770
  • 48,394
  • 7
  • 105
  • 133
  • Great points, thank you. I am using EF Core and recently started fiddling with the `InMemory` provider, which is actually what caused me to ask this question. It seems to me that Microsoft with this move, seems to replace the traditional repository pattern (which would of course benefit them, since people then stick with their databases). – Jakob Busk Sørensen Dec 04 '19 at 08:32
1

EF isn't a layer, it's a data access technology.

EF calls should be written inside a repository, which serves as an abstraction to the service layer so that the service layer doesn't care if the data are stored in a database or somewhere else.

John Wu
  • 50,556
  • 8
  • 44
  • 80
  • 2
    I agree with that. But then Entity Framework introduced `InMemory`, which has caused me to rarely feel that I need to mock repositories anymore. So it seems to me that Entity Framework is trying to take over the place of the more "normal" repository, if you know what I mean? – Jakob Busk Sørensen Dec 04 '19 at 08:25
  • 3
    It's not just about mocking. You might have a repository that accesses a microservice to store its data, or might talk to a mainframe, who knows, and you may have several third party services your system needs to call. The point of the repository is so service layer developers don't have to concern themselves with how those things all work. They just worry about writing business rules that interact with abstractions that are exposed by the repository. – John Wu Dec 04 '19 at 08:34