When building applications with ASP.Net Core and Entity Framework, Microsoft often recommends in their official training (including course 20486D) that developers use the Repository Pattern to further abstract Entity Framework. And it used to make sense.
However, it turns out this is an outdated approach, coming from back in the day when Entity Framework didn’t allow easy unit testing or using mock context, and when injecting the database context into a web request was difficult. Now that Entity Framework Core readily supports unit testing and mock contexts, and injecting the database context into the web request is easily accomplished using a service using Dependency Injection (see this post), people generally seem to feel that using the Repository pattern with Entity Framework is an unnecessary abstraction.
A couple of highlights extracted from (or inspired by) the links below:
- EF6+ is fully compatible with Unit Testing, as you can easily mock the database context and use an in-memory test db or some other test db. This wasn’t easy/possible in earlier EF versions.
- Dependency Injection in ASP.Net MVC Core makes it very easy to share the database context across an entire request, which is one of the reasons people used the repository pattern in past versions of ASP.Net.
- Entity Framework already implements a repository pattern. DbContext is your UoW (Unit of Work) and each DbSet is the repository. Implementing another layer on top of this is not only redundant, but makes maintenance harder.
- Using EF Core directly allows you to use all of EF Core’s features to produce high-performing database accesses.
Links to the articles/posts that helped convince me: