Autofac
One of the nice things about Autofac is how the modules are strucutred. If we look at a basic setup of Autofac within WebAPI it might look something like this: var builder = new ContainerBuilder();
builder.RegisterModule(new WebApiIocModule());
IocProxy.Container = _builder.Build();
var resolver = new AutofacWebApiDependencyResolver(IocProxy.Container);
GlobalConfiguration.Configuration.DependencyResolver = resolver;
_builder = null;
The part I'd like to highlight is the "RegisterModule" function. This allows me to register a class responsible in the project for building up the IOC container with the correct types. It might look as simple as this for the sake of this example:
public class WebApiIocModule : Module
{
protected override void Load(ContainerBuilder builder)
{
if (builder == null)
throw new ArgumentNullException("builder");
builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
//Cascade
builder.RegisterModule(new DomainIocModule());
}
}
And our DomainIocModule might be a little more complex, like this:
public class DomainIocModule : Module
{
protected override void Load(ContainerBuilder builder)
{
if (builder == null)
throw new ArgumentNullException("builder");
builder.RegisterAssemblyTypes(typeof(IProductService).Assembly)
.Where(t => t.Name.EndsWith("Service") || t.Name.EndsWith("Mapper"))
.AsImplementedInterfaces()
.PropertiesAutowired()
.InstancePerLifetimeScope();
//Cascade
builder.RegisterModule(new DataAccessIocModule());
}
}
The DomainIocModule will exist in our domain layer which means we have an easy way to maintain the separation between our data layers and web layers without a DI/IOC breaking it.
Resolving Types by configuration using Autofac
The most common uses for resolving by configuration is when using plugins, or when you need to allow for "hot swapping" of a particular type. To give you an example, let's say your Web API will be deployed to different servers, each having a different back end system. The data sources for your API will vary from SQL Server to CRM Systems. For this reason you have a generic "DataAccess" layer, but you need to plugin a different implementation depending on where the API is running. What you can do in Autofac is use an Xml configuration to register your modules, like this:Web.Config
<configuration>
<configSections>
<section name="autofac" type="Autofac.Configuration.SectionHandler, Autofac.Configuration" />
</configSections>
<snip...>
<autofac>
<modules>
<module type="DataAccess.Sql.Ioc.SqlIocModule, DataAccess.Sql" />
<module type="DataAccess.Crm.Ioc.CrmIocModule, DataAccess.Crm" />
</modules>
</autofac>
</configuration>
Data Access Module
public class DataAccessIocModule : Module
{
protected override void Load(ContainerBuilder builder)
{
if (builder == null)
throw new ArgumentNullException("builder");
builder.RegisterModule(new ConfigurationSettingsReader("autofac"));
}
}
All you require for the above to work is the Autofac Configuration dll/package.
Resolving all of this in a Unit Test project
You'll start running into problems pretty quickly when testing if you don't do some form of configuration. This could be as complex as writing a specific testing module to override/mock up your classes, or it could be as simple as just enabling Autofac so that it creates all objects as per your code base. There are a few different ways to solve this problem, but what I usually do is create a base class for my tests so that they can all benefit from the Autofac setup. It will look something like this: public class TestBase
{
public TestBase()
{
IocProxy.Container = TestsIocBuilder.Build();
}
}
My TestIocBuilder looks pretty much identical to my code in the very first snippet, apart from it registers a class called "TestsIocModule" instead. My TestIocModule looks something like this:
public class TestsIocModule : Module
{
protected override void Load(ContainerBuilder builder)
{
if (builder == null) throw new ArgumentNullException("builder");
//Cascade
builder.RegisterModule(new DomainIocModule());
}
}
That's pretty much it really. The DomainIocModule will cascade down for you so everything will be resolved as per your standard Autofac configuration.
What about my Xml Configuration!
The last step we need to think about is the Xml configuration for plugins. This doesn't get read by the testing project so we need to add an application configuration to our test project instead. It will contain exactly the same configuration as the Web.Config so you can pretty much copy it from above.Some of my tests fail... but only if I run ALL my unit tests!!!
This can happen when you have dodgy Autofac config in your testing libraries. What happens is the first library that comes along and registers all of your Autofac modeles and this may cause subsequent tests to fail. For example, let's say I had an integrations test project and a unit tests project. If by accident I mistyped my module in the configuration file like this: <configuration>
<configSections>
<section name="autofac" type="Autofac.Configuration.SectionHandler, Autofac.Configuration" />
</configSections>
<snip...>
<autofac>
<modules>
<module type="DataAccess.Sql.Ioc.SqlIocModule, DataAccess.Slq" />
<module type="DataAccess.Crm.Ioc.CrmIocModule, DataAccess.Crm" />
</modules>
</autofac>
</configuration>
But in the other config you have correctly named the module. This can cause you major confusion! Mainly because you might be happily writing and running unit tests that are passing first time, but as soon as you run all tests they start to fail! Be mindful of this when setting up IOC/DI across multiple test projects.
