Register the DbContext in my repository instead of the WebApi c# dependency-injection entity-framework-core repository-pattern


I have a question regarding the repository and service pattern in combination with ASP.NET Core and EF Core. I'm in the stage of learning all of this, so I might miss the clear picture fully in front of me right now.

My current project structure looks as follows:

  • Project.Repository.Contracts
  • Project.Repository.EF
  • Project.Repository.FakeData
  • Project.Service.Contracts
  • Project.Service
  • Project.WebAPI
  • WebApp

In my understanding of the repository pattern, only the Project.Repository.EF project does know about EntityFramework.

But all "Repository, Service, ASP, EF" examples register the DbContext in the ConfigureService method in the WebAPI. By calling services.AddDbContext.

Isn't this a break of the concept?

I want to avoid to have the EntityFramework dependency in my WebApi.

So my question is, how can i archieve this?

This is my code so far:


public class Startup
    public Startup(IConfiguration configuration)
        Configuration = configuration;

    public IConfiguration Configuration { get; }

    // This method gets called by the runtime. Use this method to add services to the container.
    public void ConfigureServices(IServiceCollection services)


public class Module
    public static void ConfigureServices(IServiceCollection services)
        services.AddSingleton<IProjectService, ProjectService>();
        services.AddSingleton<IProjectRepository, ProjectRepositoryEF>();

The Service and Repository are just stubs at the moment.

So again, what I want to avoid is, that I have to call services.AddDbContext in my Project.WebAPI.Module.cs class.

What I want to, is to register the DbContext in my Project.Repository.EF Project without hardcoupling it with my WebAPI.

Is this even possible?

3/19/2018 10:19:23 PM

Accepted Answer

Ok so let me make it a bit clearer for you.

The Repository pattern is more than just a data access layer that does some CRUD operations but I will try to limit my answer just to your problem to help you understand it.

(Keep in mind that the answer below is only relevant if you have a need to use repositories)

First lets talk a bit the naming of your projects. The project Project.Repository.Contracts should be renamed to Project.Repository.DTOs to make it clearer. This project contains Data Transfer Objects which is what your DataContext will use to generate your db and handle all the operations.

Then the Project.Service.Contracts can be renamed to Project.Domain in which you will have all your business logic related models.

Automapper will be used to do the two way mapping from dtos to domain objects and vice versa.

Now we will have to split your Project.Repository.EF project to two different projects. You see, the repositories only need to know about the data context. EF doesn't need to know about the repositories.

So from the Project.Repository.EF project you will create Project.Data and Project.Repository Your migrations and data context itself is in the Data project while the repositories are in the Repository project which references the Data project.

Now the Data project can be refered in the API project in order to be used in the startup class and as long as the services only know about the repositories project (and the web project only about services), you should be fine.

I would also make an extension method in the Data project instead of a static call like this Project.WebApi.Module.ConfigureServices(services);. It's cleaner.

You can also have your Startup class in a shared project between the dependencies and reference this single project on the project from which you start the host as well. Keep in mind that both DbContext, Services and repositories need to be configured at the IoC somehow. My cuppa is to create assembly markers and use Scrutor to scan for these dependencies.

EDIT: As Camilo suggested however, there's absolutely no need for a repository pattern in Entity Framework Core. EF Core is based on interfaces so you can implement your own classes around them.

The main reason why you would need a repository on top of EF was mocking. This is no longer needed because:

  1. In memory database built-in into EF Core
  2. Is based on interfaces so you can implement your own classes around them
3/19/2018 10:33:56 PM

Popular Answer

This may not be the best answer or the one you're looking for, but I hope it helps.

Isn't this a break of the concept?

From an idealistic view, perhaps. The important portion that you're separating out into another project(s) is the implementation of your repository, the setup of your context (mappings, etc).

The value in that is two-fold (at least):

  1. You can reuse these in other projects
  2. You can switch them out with a different implementation (with a matching interface) within the same WebAPI project. For instance, if you were supporting a legacy database and a new database.

Is this even possible?

Possibly with extra work and complexity, but is it practical? IME, I haven't seen a situation where it would improve the readability and maintainability of the code.

The question I would ask is, Am I going to need to dynamically choose between EF and a completely different repository type (such as Dapper, NHibernate, etc)? If the answer is no, or even not in the near future, I wouldn't add to the complexity.

As my grandmother used to say, "Don't borrow trouble." If you do need to completely switch to a different repository framework / ORM down the road, switching out the lines in ConfigureServices will be trivial. It's only complicated if you need to support two or more at once.

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow