Share Microsoft.Extensions.DependencyInjection.ServiceProvider configuration between projects

Question

I have a solution that has the following projects

• Acme.Core
• Acme.Domain
• Acme.Repositories
• Acme.Services
• Acme.Web

In the past I've used Unity for DI in full framework projects. I was able to register concrete objects to interface mappings in executable projects (web apps, console app, test apps).

I'm trying to implement the same approach with .NET Core. I wanted to first try using the Microsoft.Extensions.DependencyInjection library. Within the ASP.NET Core application it works great. Unfortunately I've run into an issue when I try to share/reference that instance with the registions to other projects, such as a .NET Standard library.

My idea was to inject the ServiceProvider into the constructor of the service:

public class AddressService : BaseService, IAddressService
{
        private readonly IServiceProvider _serviceProvider;

        public AddressService(IServiceProvider serviceProvider, string userOrProcessName)
        {
           _serviceProvider = serviceProvider;
        } 

        public IReadOnlyList<IState> GetAllStates()
        {
            _serviceProvider.GetService<IAddressRepository>();

            // other logic removed
        }
}

I tried the following inside the Startup.ConfigureServices():

services.AddTransient<IAddressService>(s => new AddressService(HttpContext.RequestServices, Environment.UserName));

The issue I ran into is that I cannot reference HttpContext.RequestServices outside of a Controller. I haven't been able to figure another way of passing the ServiceProvider instance.

My questions:

1. How do pass a reference for the current ServiceProvider?
2. Is there a better design to accomplish my goal sharing the configuration of Microsoft.Extensions.DependencyInjection in multiple libraries?

Answer 1

Prevent injecting IServiceProvider into your application components; that leads to the Service Locator anti-pattern.

Instead, you should build up application components solely using Constructor Injection. This means that your AddressService should require IAddressRepository as constructor argument, not IServiceProvider. For instance:

public class AddressService : IAddressService
{
    private readonly IAddressRepository repo;

    public AddressService(IAddressRepository repo, IUserContext userContext)
    {
       this.repo = repo;
    } 

    public IReadOnlyList<IState> GetAllStates()
    {
        // other logic removed
    }
}

Also try to prevent injecting primites into your constructors. It's not a bad practice per se, but it does complicate object graph construction. Instead, either wrap the value into a class, in case its a configuration value, or hide it behind an abstraction (as shown above) in case it's a runtime value.

Both practices simplify both your application code and the Composition Root.

For instance, this will be the result of the previous AddressService redesign:

services.AddTransient<IAddressRepository, SqlAddressRepository>();
services.AddTransient<IAddressService, AddressService>();
services.AddScoped<IUserContext, UserContext>();
services.AddHttpContextAccessor();

Here, UserContext could be defined as follows:

public class UserContext : IUserContext
{
    private readonly IHttpContextAccessor accessor;
    public UserContext(IHttpContextAccessor accessor) => this.accessor = accessor;
    public string UserName => this.accessor.HttpContext.User.Identity.Name;
}

Answer 2

In order to share configuration across multiple projects, you can put the configuration into a shared assembly, and register (not resolve) them in there. Many dependency injection libraries offer that functionality. e.g.

• in Autofac you create a module (https://autofaccn.readthedocs.io/en/latest/configuration/modules.html) that takes a container builder to configure:

  protected override void Load(ContainerBuilder builder) { ... }
  

• SimpleInjector provides packages: https://simpleinjector.readthedocs.io/en/latest/howto.html#package-registrations

• Unity can support something similar: Can I register my types in modules in Unity like I can in Autofac?

• Ninject has a similar module feature: What is the intention of Ninject modules?

• A similar feature has be created for Microsoft.Extensions.DependencyInjection: https://github.com/aruss/DotNetCore_ModularApplication

At a high level, you create a method that receives the DI container and adds your registrations to that container. If your DI framework doesn't provide hooks you need to manually call the method yourself, but the general concept doesn't change.

Splitting registrations into modules allows you to easily group similar sets of functionality while maintaining the flexibility of incorporating different sets of functionality into different projects. You could of course create a single shared assembly that registered the union of all dependencies for all projects, but that would carry around unnecessary baggage and result in a less reusable implementation.

The key point as Steven points out is that you configure the container and let it inject the dependencies rather than looking from the inside out for the dependencies.