NET Core dependency injection - resolve service or configuration based on dependent class

Question

Assuming this use case:

You've got two classes X and Y that depends on a configuration of type Config

public class X
{
    public X(IOptions<Config> config)
    {
    }
}

public class Y
{
    public Y(IOptions<Config> config)
    {
    }
}

Now, you want to create each an instance of X and Y, but with different configurations. What would be the right way to register this?

From everything I read, the only way to solve this would be by adding some sort of "naming" for the different configuration instances and resolve them via a custom resolver:

public delegate Config ServiceResolver(string key);

services.AddTransient<ServiceResolver>(serviceProvider => key =>
{
    switch (key)
    {
        case "A":
            return ... (whatever to get the first config instance);
        case "B":
            return ... (whatever to get the second config instance);
        default:
            throw new KeyNotFoundException();
    }
});

However, this means that the implementation of each X and Y must know about details about how to get the configurations:

• They must know the correct name (A or B) and
• they must know the ConfigResolver type, which is only an implementation detail/helper class for the sake of dependency injection.

This problem hits even harder if you need to go through several stages of dependencies, like

Config (A)         Config (B)
   |                  |
   v                  v
Service            Service
   |                  |
   v                  v
   X                  Y

My feeling is, there should be a better way to solve this. Like some form of receipent dependent service factory:

Host.CreateDefaultBuilder(args).ConfigureServices((context, services) => {
    services.Configure<Config>(context.Configuration.GetSection("ConfigA")).For<X>();
    services.Configure<Config>(context.Configuration.GetSection("ConfigB")).For<Y>();
});

and maybe

Host.CreateDefaultBuilder(args).ConfigureServices((context, services) => {
   services.AddTransient<Service>((services, receiverType) => {
      if(receiverType == typeof(X)) {
        ... resolve a service instance;
      }
      else {
        ... resolve some other service instance;
      }
   });
});

So, is there just some feature I missed until now? Is my understanding of the situation totaly misguided? Or is this really a feature that should be, but has not been added until now?

---

EDIT:

To make my point clearer: Just assume that X and Y are classes of a third-party library. Their constructors signature cannot be changed by you, as you don't have access to the source code.

So, how would you set this up in a way that you can get each an instance of X with ConfigA and an instance of Y with ConfigB?

---

Another EDIT 2023-01-02:

Happy new year everyone :)

Seems I have to describe a bit better what's my problem. This is not constrained to IOptions/configurations, but more a general question about where to decide about which service to inject and how it is configured.

Assume I have two a congress location with 2 stages. I call them "bigStage" and "smallStage", but in the end they've got the same implementation. I also got two speakers invited, called "loadSpeaker" and "quietSpeaker", but at this moment in time I don't know which one will speak on which of the two stages.

So I decide I've got this setup:

class Stage {
  public Stage(string name, ISpeaker speaker) {
    ...
  }
}

class Speaker: ISpeaker {
  public Speaker(string name) {
    ...
  }
}

Now, at the latest time possible, I want to compose my final setup so that I've got 2 Stages (called bigStage and smallStage) and their assigned Speakers (loudSpeaker on bigStage and quietSpeaker on smallStage). This composition/assignment should completely happen in my composition root, so that no code changes have to happen in the rest of my code. How can I do that?

Answer 1

I suggest to use a factory for your Service:

class X {
    private readonly Service _service;
    public X(ServiceFactory serviceFactory) {
        _service = serviceFactory.Create<X>();
    }
}

class Service {
    private readonly Config _config;
    public Service(Config config) { _config = config; }
}

class ServiceFactory {
    private readonly IConfiguration _configuration;
    /* other Service dependencies would also be injected here */
    public ServiceFactory(IConfiguration configuration, /* Service dependencies */) {
        _configuration = configuration;
        ...
    }

    public Service Create<T>() {
        return Create(typeof(T));
    }

    public Service Create(Type type) {
        var configName = switch typeof(T) {
            X => "ConfigX",
            Y => "ConfigY",
            default => throw new Exception()
        };
        var config = _configuration.GetSection(configName).Get<Config>();
        return new Service(config, /* other dependencies */);
    }
}

The switch statement can be replaced with a Dictionary<Type, string> or Dictionary<string, string> if you would want to export this dictionary to IConfiguration.

Getting the Config can be also cached for performance (don't forget the thread safety)

Answer 2

So the "trick" to all of this is... you have to piggy back onto ~something to make a decision on which one IMySomething . when you register multiple IMySomething(s).

The factory above where you switch/case on the object.TYPE....is one way. But it is "fragile", IMHO. Or at the very last, violates the Open/Closed principle of SOLID, as you have to keep editing the code to add a new case-statement.

So I also think you want a Factory.......BUT I do not like "hard coding" the values of the switch/case statements.

So if you follow my IShipper example:

Using a Strategy and Factory Pattern with Dependency Injection

I think you want to create a

IShipperFactory

and inject the IEnumerable of "IShipper"(s).

..

Then you will use your IShipperFactory... when registering your things that need an IShipper.

This does cause a small "ripple" because you need access to the IShipperFactory....to do (later) IoC registrations.

But it would be "clean" and have good separations of concerns.

Let me pseudo code it.

public interface IShipper (from other article)

3 concretes (Usps, FedEx, Ups)

public interface IShipperFactory()
  public IShipper GetAnIShipper(string key)

..

public class ShipperFactoryConcrete
    (from other article, inject multiple IShippers here)

    public IShipper GetAnIShipper(string key)
    // look through the injected IShippers to find a match, or else throw exception.

.....

public interface IOrderProcessor

..

public class WestCoastOrderProcessor : IOrderProcessor
    /* c-stor */
    public WestCoastOrderProcessor(IShipper aSingleShipper)

---

public class EastCoastOrderProcessor : IOrderProcessor
    /* c-stor */
    public WestCoastOrderProcessor(IShipper aSingleShipper)

........

Ok, so we decide at compile-time, we want to define the "best" IShipper for the EastCoastOrderProcessor and WestCoastOrderProcessor. (making up some kind of example here)

So need need to IoC register.

from the other article:

cont.RegisterType<IShipper, FedExShipper>(FedExShipper.FriendlyName);
cont.RegisterType<IShipper, UspsShipper>(UspsShipper.FriendlyName);
cont.RegisterType<IShipper, UpsShipper>(UpsShipper.FriendlyName);

now it gets a little "off beaten path".

See:

https://stackoverflow.com/a/53885374/214977

and

// so this is a cart-horse situation, where we need something from the IoC container.... to complete the IoC registrations.

  IShipperFactory sf = services.GetRequiredService<IShipperFactory>(); // see https://learn.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection?view=aspnetcore-7.0#resolve-a-service-at-app-start-up

.. and now we IoC register...but we specify specific values for the constructor. please see the SOF (214977), for syntax-sugar hints. the below is definately pseduo code.....

_serviceCollection.AddSingleton<IOrderProcesor>(x => 
    ActivatorUtilities.CreateInstance<EastCoastOrderProcessor>(x, sf.GetAnIShipper(FedExShipper.ShipperName));
);

_serviceCollection.AddSingleton<IOrderProcesor>(x => 
    ActivatorUtilities.CreateInstance<WestCoastOrderProcessor>(x, sf.GetAnIShipper(UspsShipper.ShipperName));
);

APPEND:ONE:

Another "trick" .. if you have a code base that you cannot change is.

The "proxy design pattern":

The Proxy design pattern provides a surrogate or placeholder for another object to control access to it.

https://www.dofactory.com/net/proxy-design-pattern

public EastCoastOrderProcessorProxy

  private readonly ThirdPartyOrderProcessor innerThirdPartyOrderProcessor;

    public EastCoastOrderProcessor(ThirdPartyOrderProcessor innerThirdPartyOrderProcessor)
    {
        this.innerThirdPartyOrderProcessor = innerThirdPartyOrderProcessor;
    }

..

public WestCoastOrderProcessorProxy

  private readonly ThirdPartyOrderProcessor innerThirdPartyOrderProcessor;

    public EastCoastOrderProcessor(ThirdPartyOrderProcessor innerThirdPartyOrderProcessor)
    {
        this.innerThirdPartyOrderProcessor = innerThirdPartyOrderProcessor;
    }

So while you cannot change the ThirdPartyOrderProcessor, you can write 1:N wrapper-proxies around it.

Answer 3

The simplest solution I can think of, without using named options inside of your service classes, is moving the selection of the configuration object from the class constructor to the composition root of the application.

This way, your service class simply receives a configuration object as a constructor parameter and it is not aware of the underlying configuration infrastructure.

The composition root, which is in charge of composing the objects which make your application, do know about the configuration infrastructure and picks the right configuration object for your services.

In order to implement this pattern, you need to define an option class as the first step. This option class is needed in order to leverage the options pattern support offered by ASP.NET core. You will only use this class at the composition root level.

public sealed class LayoutOptions
{
    public const string Layout = "Layout";
    public const string Basic = "Basic";
    public const string Complex = "Complex";

    public string Name { get; set; } = default!;
    public string Color { get; set; } = default!;
    public int NumberOfColumns { get; set; }
}

Then you need to define a class which represents the configuration object for your services. This is basically a strongly typed configuration object used to configure your services. This object is built strating from the options class, notice that you don't need to make it identical to the options class itself.

public sealed class LayoutConfiguration
{
    public string Name { get; }
    public string Color { get; }

    public LayoutConfiguration(string name, string color)
    {
      Name = name;
      Color = color;
    }
}

Now you need to define your service classes. These types are configured by using the LayoutConfiguration configuration class. Each service class will be properly configured by the composition root of the application, by using the proper named options.

public interface ILayoutService
{
    string GetLayoutDescription();
}

public sealed class BasicLayoutService : ILayoutService
{
    private readonly LayoutConfiguration _config;

    public BasicLayoutService(LayoutConfiguration config)
    {
      _config = config ?? throw new ArgumentNullException(nameof(config));
    }

    public string GetLayoutDescription() =>
      $"Basic layout description. Name: '{_config.Name}' Color: '{_config.Color}'";
}

public sealed class ComplexLayoutService : ILayoutService
{
    private readonly LayoutConfiguration _config;

    public ComplexLayoutService(LayoutConfiguration config)
    {
      _config = config ?? throw new ArgumentNullException(nameof(config));
    }

    public string GetLayoutDescription() =>
      $"Complex layout description. Name: '{_config.Name}' Color: '{_config.Color}'";
}

You can also defined a couple of controllers, that you can use to test this implementation and be user that your services are wired-up correctly by the composition root of the application:

  [ApiController]
  [Route("[controller]")]
  public sealed class BasicLayoutController : ControllerBase
  {
    private readonly BasicLayoutService _basicLayoutService;

    public BasicLayoutController(BasicLayoutService basicLayoutService)
    {
      _basicLayoutService = basicLayoutService ?? throw new ArgumentNullException(nameof(basicLayoutService));
    }

    [HttpGet("description")]
    public string GetDescription() => _basicLayoutService.GetLayoutDescription();
  }

  [ApiController]
  [Route("[controller]")]
  public sealed class ComplexLayoutController : ControllerBase
  {
    private readonly ComplexLayoutService _complexLayoutService;

    public ComplexLayoutController(ComplexLayoutService complexLayoutService)
    {
      _complexLayoutService = complexLayoutService ?? throw new ArgumentNullException(nameof(complexLayoutService));
    }

    [HttpGet("description")]
    public string GetDescription() => _complexLayoutService.GetLayoutDescription();
  }

This is the most important part. Put this registration code inside the Program.cs class (which is the composition root for an ASP.NET core 6 application):

      // Configure named options 
      builder.Services.Configure<LayoutOptions>(
        LayoutOptions.Basic,
        builder.Configuration.GetSection($"{LayoutOptions.Layout}:{LayoutOptions.Basic}")
      );

      builder.Services.Configure<LayoutOptions>(
        LayoutOptions.Complex,
        builder.Configuration.GetSection($"{LayoutOptions.Layout}:{LayoutOptions.Complex}")
      );
      
      // Register the BasicLayoutService by picking the right configuration
      builder
        .Services
        .AddScoped(serviceProvider =>
        {
          // Get named options 
          var layoutOptions = serviceProvider.GetRequiredService<IOptionsSnapshot<LayoutOptions>>();
          var basicLayoutOptions = layoutOptions.Get(LayoutOptions.Basic);

          // Create strongly typed configuration object from named options
          var configuration = new LayoutConfiguration(
            basicLayoutOptions.Name,
            basicLayoutOptions.Color);

          // Creates new instance of BasicLayoutService using the service provider and the configuration object
          return ActivatorUtilities.CreateInstance<BasicLayoutService>(
            serviceProvider,
            configuration);
        });

      // Register the ComplexLayoutService by picking the right configuration
      builder
        .Services
        .AddScoped(serviceProvider =>
        {
          // Get named options 
          var layoutOptions = serviceProvider.GetRequiredService<IOptionsSnapshot<LayoutOptions>>();
          var complexLayoutOptions = layoutOptions.Get(LayoutOptions.Complex);

          // Create strongly typed configuration object from named options
          var configuration = new LayoutConfiguration(
            complexLayoutOptions.Name,
            complexLayoutOptions.Color);

          // Creates new instance of ComplexLayoutService using the service provider and the configuration object
          return ActivatorUtilities.CreateInstance<ComplexLayoutService>(
            serviceProvider,
            configuration);
        });

You can now test this implementation. As an example, you can set the following configuration in appsettings.json:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "Layout": {
    "Basic": {
      "Name": "Basic Layout",
      "Color": "red",
      "NumberOfColumns": 2
    },
    "Complex": {
      "Name": "Complex Layout",
      "Color": "blue",
      "NumberOfColumns": 3
    }
  }
}

If you run this application and you issue a GET request to /BasicLayout/description, you ge the following response:

Basic layout description. Name: 'Basic Layout' Color: 'red'

If you issue a GET request to /ComplexLayout/description the response you get is:

Complex layout description. Name: 'Complex Layout' Color: 'blue'

A final note on the service lifetime for BasicLayoutService and ComplexLayoutService. In my example I decided to register them as scoped services, because you may want to recompute the configuration object for them (LayoutConfiguration) for each incoming request. This is useful if your configuration may change over time. If this is not the case, you can safely register them as singleton services. That's up to you and depends on your requirements.