Passing runtime-read configuration when working with an IoC container

Question

I've recently "discovered" the IoC realm, and decided to refactor a project I'm working on to use such a container.
To be specific - I'm using autofac in C#, in a .NET Core console application.

The program reads some configuration at startup, doesn't really matter how, just that it's all wrapped nicely with interfaces, especially an IConfigurationReader which reads it and returns a matching class.
There are many possible configurations, each has its own class (e.g. NetConfig for, well, network configuration), but eventually they're all part of a main AppConfig - As properties.
Reading the configuration should be the first thing the program does, then it should pass some of the configurations to other aspects of the system for further processing. Let's focus on NetConfig for now.

Up till now, aspects of the system that require NetConfig were accepting it as a concrete class, but there are a few problems with it:

1. It's bad design when living in a DI-Aware system. Would be better to accept a Provider instead.
2. I need to share the same configuration instance between all those modules that require it, similarly to a Singleton (Wouldn't implement one of course). A concrete provider, implementing the one suggested above, would be a nice & clean solution to this.

All right, say I've changed all NetConfig-dependent modules to accept an INetProvider instead.
A Singleton-like implementation of this provider should somehow provide the NetConfig, that's its purpose after all, but it can't do that without getting it from somewhere else first, e.g. as a ctor parameter.
Problem is, that this NetConfig instance is only created at runtime, reading it from some external source, so when registering with an IoC container, the NetProvider can't be registered as there's no NetConfig yet.

What should I do to resolve it? I've read many of the docs of autofac but it seems like none of their examples solve anything like this.

Answer 1

Some things to think about:

• Creating the IoC container need not be the first thing you do. In fact, reading configuration should generally happen first, partially because other aspects of the IoC configuration might depend on that too. For example, maybe your configuration lets you switch between completely different data sources, that therefore require different repository implementations to be registered.

So read the configuration first, and then base the service registration on that.

• There's nothing wrong with simply accepting a concrete instance of a configuration class in an IoC scenario. You can totally register your various configuration classes as singletons (using RegisterInstance in autofac), without there being any interface. Then have the classes that care about the configuration take the configuration as an injected parameter.

The specific NetConfig example you brought up might make you think that's a bad idea, but that might be more because the classes using it were too coupled to whatever they needed the NetConfig for. In that case, a INetProvider might be a good idea if you can factor that part out; or maybe what you really want is to inject a HttpClient (or rather, for testability, an abstracted version of it) into some of those classes, and some kind of mail sender or RPC abstraction into others.

• .Net Core already has a facility for using configuration with IoC. The Microsoft.Extensions.Options NuGet package (and its siblings) provides facilities to
  • Read configuration from a variety of sources: command line, environment variables, JSON and XML files, and you can extend with your own parsers too.
  • Map the configuration to concrete classes.
  • Inject those concrete classes (behind an IOptions wrapper) into your classes via IoC.
  • Perform post-processing on the configuration.
  • Monitor configuration files for changes and update the application as necessary.

This facility is not tied to ASP.Net Core; it's usable independently. It is easier to use in conjunction with Microsoft's own IoC container rather than autofac due to some convenience extension methods, but it's not dependent on it.

Answer 2

For the sake of illustration, let's say that the classes you need to register depend on a type called IConfigurationValues. It could be an interface or a concrete type.

You can pass the configuration values to your module as a constructor argument like this:

public class MyModule : Autofac.Module
{
    private readonly IConfigurationValues _configuration;

    public MyModule(IConfigurationValues configuration)
    {
        _configuration = configuration;
    }

    protected override void Load(ContainerBuilder builder)
    {
        builder.Register(cb => _configuration).As<IConfigurationValues>();
        // register your other stuff
    }
}

It's now impossible to use the module without supplying the configuration values. This makes the expected behavior explicit and easy to follow. The application knows that the dependencies it is going to register need these values, and it has to supply them.

The classes that depend on the configuration values don't know where they came from, so they're not coupled to whatever provides the configuration.