March 26, 2011
Castle Windsor is an Inversion of Control Container which has excellent documentation, written by Krzysztof Koźmic. Krzysztof has written a perfect tutorial on ASP.NET MVC 3, which I thought I would follow. And then I found that Castle Windsor is extremely easy and transparent to use. And it has a cool name at that.
What again is Inversion of Control and why ever would I use it?
Suppose you develop a member administration tool and the customer wants to use an MySQL database. But you coded the app with Linq to SQL. Wouldn't it be nice if you could just change your ORM from L2S to EF? Or Nhibernate?
Or, what if you coded your app with an object database, and then later you find that the customer has a DBA who is absolutely against NoSQL?
The same goes for the logging framework. Which one? Log4Net or Elmah?
With IOC you can just pick and choose which framework you plug in. When you start with one choice of a product, you are not bound to it.
It's called Inversion of Control because it's an inverted API. With an API, you use the methods it exposes. With IOC, you let your application choose which API to use. Huh? Yeah. Because when your app spins up, it uses reflection to get all the dependencies you configured within your container. Now, does that make any sense?
A simple example
Here's how the principle works.
In an ASP.NET MVC architecture, there is a Model, a View and a Controller. The Controller sits between the Model and the View, so the Controller would be a good place where we can inject some dependencies. How to inject these dependencies? Well, by their constructor.
The default controllerfactory has a parameterless constructor, so we need to override that, by creating a new class. E.g. WindsorControllerFactory. And we let our controllerfactory inherit from DefaultControllerFactory.
We need to override two methods: ReleaseController (so that he Windsor Controller is released) and getControllerInstance (which returns a Windsor Controller). This bit of plumbing code just provides the MVC runtime with new instances of the controller type for each request and when the request ends, it releases the controller.
Next, we need to register the controllers in to the container with an Installer, like this:
This is how we register types in the container, so there will me more of these classes later.
Now we need to bootstrap this in global.asax:
And then we are ready to roll.
In part 2 I will show how to create some interfaces and inject them in the controller.
Here is the complete example.