asp.net 5 dependency injection in multiple projects

Question

I've got an ASP.NET 5 dnxcore solution with some projects to separate my logic:

• API
• Core (with services for business logic)
• DAL (repository interfaces)
• Entity Framework (the repositories implementations)

Now I use DI to call my services in the constructors of my API controllers:

private readonly IMyService _myService;
public Controller(IMyService myservice){ _myService = myService; }

The services in my core get the repository thru constructor injection too:

private readonly IMyRepository _myRepo;
public MyService(IMyRepository myRepo){ _myRepo = myRepo; }

Currently I need to define my DI container in the startup class of my API to make it work.

My question is, how can I put the 'building' of the DI container of the repositories in my services in my Core-project. This way, my API is loosely coupled of the fact that my services use Entity Framework, so I can change to, for example, mongodb without changing my API project.

Answer 1

My question is, how can I put the 'building' of the DI container of the repositories in my services in my Core-project. This way, my API is loosely coupled of the fact that my services use Entity Framework, so I can change to, for example, mongodb without changing my API project.

You could, but you shouldn't do that.

Dependency Injection is the practice of making loosely-coupled classes throughout the libraries that can be plugged together (often in many ways).

However, each application should have a composition root, which is the one place in the application where we put the coupling code. Our first instinct as developers is to try to farm the coupling code off into its own library, but that is an urge that you should resist. See composition root reuse.

Mark Seeman's illustration sums it up well. Avoiding transitive dependencies is what is desired when using DI in order to flatten the dependency graph. This ensures assemblies can be used/tested in isolation without dragging along unnecessary dependencies, which in turn makes maintenance easier.

That said, many DI containers have a way to organize the configuration of certain parts of the application by using modules. In Autofac, the documentation for modules is here.