Modularize ASP.NET DI configurations using Autofac

When working on a monolith in ASP.NET the Startup.cs tends to get messy as more and more services are added.

Nevertheless, with the Microsoft.Extensions.DependencyInjection being the new and good default for libraries to provide means for configuration, I want to use these extension methods to setup my dependency injection container of choice, which is Autofac.

Modularizing the configuration in Autofac

Autofac always provided means to easily modularize its configuration using Modules.

Basically you add a new class inheriting from Module and override Load.

public class AModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        builder.RegisterType<MyType>();
    }
}

Then you are registering the module in the configuration.

builder.RegisterAssemblyModules(typeof(Startup).Assembly); // Register all modules in assembly
builder.RegisterModule(typeof(AModule)); // Register single module
builder.RegisterModule<AModule>(); // Register single module using generics

Integrating Microsoft.Extensions.DependendyInjection registrations with Autofac Modules

Autofacs integration with Microsofts DependencyInjection (https://github.com/autofac/Autofac.Extensions.DependencyInjection) adds an PopulateServices extension that allows to add all services in an IServiceCollection to the Autofac configuration.

When adding Autofac to an ASP.NET application this method is used at the end to integrate the Microsoft.Extensions.DependencyInjection services into Autofac.

public static void Populate(
            this ContainerBuilder builder,
            IEnumerable<ServiceDescriptor> descriptors)

This method can also be used in modules to add additional services to the container in a modular fashion. Here an example for a ValidationModule that adds FluentValidation to the application:

public class ValidationModule : Module
{
    protected override void Load(ContainerBuilder builder)
    {
        var services = new ServiceCollection();

        services.AddFluentValidation(fv => fv.RegisterValidatorsFromAssembly(ThisAssembly));

        builder.Populate(services);
    }
}

This method allows you to use extension methods provided by libraries for an easier integration into the .NET ecosystem in a modular, clean way located close to the code that needs it.

Conclusion

I have shown how I integrate Autofacs Module configuration with Microsoft.Extensions.DependencyInjection.

I use this method to modularize the configuration for my monolithic applications.

How are you managing your growing Startup.cs? Have you found another way to manage your dependencies in a better way?

Comments

[Oleksii Nikiforov]

I usually create file called ServiceCollectionExtensions.cs and than add extension method over IServiceCollection to register module. Usually, if project register something it has Add<ModuleName> method. For me it works. Do you see other benefits of using AutoFac instead of built-in DI?

[Georg Müller]

Usually I add different dependencies based on the feature I am working. So I split up my applications in multiple namespaces in the project. Each namespace being a well-defined set of features (or bounded context in DDD terms).
Each of these namespaces has its own module, which defines the dependencies it requires as part of the Module.
I think, when reading the code its easier to find the configurations and dependencies easier.

Do you see other benefits of using AutoFac instead of built-in DI?

I am used to it and it is a very good DI container in my point of view. It has some advanced features (but they rarely should be used).

Compared to the ASP.NET DI, I like the AssemblyScanning features, that allow to register all types implementing an interface or something like that.

As for the practices described in this blog: If you are happy with the ASP.NET DI I would suggest you keep using it. If you are already using Autofac, here you have a way to improve modularity of the ASP.NET registrations