I have been working with ASP.NET MVC over the last few days and wanted to implement dependency injection utilising Castle Windsor. I spent a while nosing around the web for some articles on this and although I found a few there wasn’t anything definitive. So once I had a working version of this on my development VM I thought I would write this post to record my findings.
Firstly, we need to hook into the Application_Start within Global.asax. In here we want to use the ControllerBuilder SetControllerFactory method to specify our own ControllerFactory that will encapsulate our Inversion of Control container of choice, in our case Castle Windsor.
/// <summary>
/// Application on start.
/// </summary>
protected void Application_Start()
{
RegisterRoutes(RouteTable.Routes);
ControllerBuilder.Current.SetControllerFactory(typeof(ControllerFactory));
}
Our custom ControllerFactory class is then defined like so
public class ControllerFactory : IControllerFactory
{
static readonly WindsorContainer container = new WindsorContainer(HttpContext.Current.Server.MapPath(“~/Windsor.config”));
public IController CreateController(RequestContext requestContext, string controllerName)
{
return (IController)container.Resolve(controllerName);
}
public void ReleaseController(IController controller)
{
container.Release(controller);
}
}
We have implemented our own version of the CreateController and ReleaseController methods. In the CreateController method we use the WindsorContainer to obtain the class to be used. This piece of logic is achieved through Convention over Configuration, with the controller name specified being the name of the controller without the Controller suffix. So for example the HomeController class would have the name “Home” and the AccountController class would have the name “Account”.
We then also explicitly release the controller in Castle Windsor to make sure there are no leaks.
The config below gives and example of the windsor config
<configuration>
<components>
<component
id=“Account“
type=“MVCDemo.Controllers.AccountController, MVCDemo“
lifestyle=“transient“/>
<component
id=“Home“
type=“ MVCDemo.Controllers.HomeController, MVCDemo“
lifestyle=“transient“>
<parameters>
<TestGateway>${testGateway}</TestGateway>
</parameters>
</component>
<component
id=“testGateway“
service=“ MVCDemo.Gateways.IGateway, MVCDemo“
type=“ MVCDemo.Gateways.TestGateway, MVCDemo“
lifestyle=“transient“>
</component>
</components>
</configuration>
In the configuration above we are defining two Controllers; the HomeController and the AccountController using the identifiers mentioned previously. These specify the concrete classes to be used.
Additionally, we are specifying that the HomeController has a dependency on the TestGateway class, which implements the IGateway interface. This is all purely for example, but this dependency could be switched easily at a later date to another class that implements the IGateway interface by simply updating this configuration file. I won’t show the definition for the TestGateway class or IGateway interface, as it is irrelevant for this example.
Finally, a modification is required to the HomeController so that the constructor accepts the dependency we have identified.
public HomeController(IGateway gateway)
Now, spinning up the application means the Account and Home controllers being used are those specified in our Windsor configuration file and we are also passing in the TestGateway to the Home controller. On top of this, we can also test the HomeController more effectively by mocking out the IGateway interface using something like Rhino Mocks.