First of all let me say that I love IoC containers. I love them not because they are trendy, or that they help testability, or that they allow me to use AOP. No, the real reason I love IoC containers is because they let me be lazy.
When I'm designing a class I don't need to worry about how I get can get a dependency. The container allows me to worry about that later, by separating construction from logic. Think about that for a second. Every time we use the new keyword we're explicitly creating a dependency between implementations. Sometimes this isn't a big deal, but if we have a dependency that itself has 10 other dependencies this can get out of hand real quick.
Containers are smart, they know which implementations fulfill which contracts. Somewhere on application startup we just tell the container what contracts and what implementations we have and it figures out the dependencies for us. If we have a FooService that requires an IBarRepository implementation, the container will automatically new up a class that implements IBarRepository and give it to FooService on creation.
Things get a bit less academic and a bit more troublesome when we try to implement a container with ASP.NET. Normally we would want the container to new up our page instance and provide any dependencies it my have, but with ASP.NET we don't get the chance to have the container create the page instances with all of its required dependencies. We could create our own page handler factory to do this, but that's a lot of work to do right.
Sprint.NET has its own page handler factory which works very well, but the last I checked, Spring.NET configuration is very verbose and requires that each page that needs the container to construct it be registered with the container. It works, but I prefer convention over configuration.
My favorite .NET container is Windsor because it allows me to do more with less work (configuration), but unfortunately there's no built in way to use Windsor in a truly IoC way with ASP.NET. The only supported way is to get a reference to the container and ask the container to resolve an instance of something, which directly makes your page dependant upon the container, and generally just adds noise where its not needed; you would see calls like this all over:
IFooService service = Container.Resolve<IFooService>();
Rather than explicitly asking the container for a service instance, I would much rather have the container inject any required dependencies into my page instance when it gets constructed. The problem is how do we do this with Windsor?
Windsor AspNetModule
The approach I've taken is to create an http module that will inject dependencies into a page just after instantiation using setter injection. This means that the container will inject any dependencies that my page may have using public property setters. Constructor injection would be better, but IMO its not worth the effort of having to create my own page handler factory, here we can rely on the tried and true ASP.NET infrastructure. Perhaps someday I'll change my mind, but for now this is acceptable.
Since I plan on using this container with a large amount of legacy code that doesn't use dependency injection I want to make the use of the container somewhat explicit. I don't want to waste cycles scanning over a page that doesn't need any dependencies injected. To enforce this, I make the pages that require injection declare so using a class level attribute. Here's a succinct example with one dependency:
[UsesInjection]
public partial class CustomerDetail : Page
{
public ICustomerRepository CustomerRepository { get; set; }
protected void Page_Load(object sender, EventArgs e)
{
customerGrid.DataSource = CustomerRepository.GetAll();
customerGrid.DataBind();
}
}
When the module sees the current handler with the UsesInjection attribute it scans the class for public setter properties and tries to resolve any dependencies by type. If an instance is registered with that type in the container, the module tries to set the property. Here an ICustomerRepository instance gets injected. All of this happens before the page lifecycle begins, so its safe to use these dependencies on page init or page load.
If more explicit control is required, we can change the module's behavior by changing the class level UsesInjection attribute.
[UsesInjection(For.ExplicitProperties)]
public partial class CustomerDetail : Page
{
private ICustomerRepository customerRepository;
[RequiredDependency]
public ICustomerRepository CustomerRepository
{
get { return customerRepository; }
set { customerRepository = value; }
}
protected void Page_Load(object sender, EventArgs e)
{
customerGrid.DataSource = CustomerRepository.GetAll();
customerGrid.DataBind();
}
}
The For.ExplicitProperties does two things:
- Optimizes the scanning process to only consider explicitly tagged properties (the default behavior considers all public settable properties).
- An exception will be thrown if a dependency couldn't be found in the container to inject. This makes is pretty evident if you forget to register a dependency with the container.
With the page level code in place we then need to setup our container and register our components. This is easily accomplished by implementing Castle.Windsor.IContainerAccessor in our global.asax and creating a static container with the registered components our web application needs to run. Here we register to use an in memory customer repository implementation.
public class Global : System.Web.HttpApplication, IContainerAccessor
{
private readonly IWindsorContainer container = new WindsorContainer();
public Global()
{
container.Register(
Component.For<ICustomerRepository>()
.ImplementedBy<InMemoryCustomerRepository>());
}
public IWindsorContainer Container
{
get { return container; }
}
}
We do this in the global.asax because we share the container between all requests, and thus only want one instance of it. Also, the IContainerAcessor is used as a service locator which is required by the AspNetWindsor http module to find your container instance which it will use to resolve dependencies.
The very last thing we need to do is register the AspNetWindsor http module in our web.config, just like any other module.
<add name="WindsorModule" type="Sneal.AspNetWindsorIntegration.AspNetDependencyBuilderModule, Sneal.AspNetWindsorIntegration"/>
From here on out, all ASP.NET requests get intercepted by this module and "enriched" by the container as long as they are tagged with the UsesInjection page level attribute.
The code is available under the Apache 2 license in my SVN repository here on Google Code. A compiled binary is also available for download.