The use of Repository and unit of work patterns (revisited) ... in EF Core with ASP.NET Core

Question

I was following this tutorial for EF Core with ASP.NET Core. The interesting thing is that this article states that 'the use of Repository and unit of work patterns is not always the best choice for applications that use EF', but in the tutorial of EF 5 the use of repository and unit of work patterns still is promoted even with a seperate tutorial part.

Reading old articles on stackoverflow it is reported that the reasons one would apply it is mainly for testing (dependency injection).

Reading further in the turial it is mentioned that 'The Entity Framework Core implements an in-memory database provider that can be used for testing'. I presume this is a new feature that was not there at the time of EF5. Does this mean that there is hardly any reason anymore to apply the use of repository and unit of work patterns in EF Core with ASP.NET Core?

Answer 1

There's many reasons and a long history for why there's so much confusion here. EF's DbContext used to not implement an interface, so it made mocking it difficult for testing purposes. However, that was corrected in EF 6, so since that time there's been absolutely no benefit, even for testing purposes, in using the repository/unit of work patterns.

EF Core is completely testable end-to-end and has an in-memory database provider as well now, which means you don't even need to mock it, though you very much can if you want.

Long and short, dump the repository and unit of work patterns. They've never been a good solution even when they had some use for testing, and since EF 6, they have been completely useless.

Now... let the flame war begin.