Dependency Injection using Castle Windsor

Castle WindsorHave you ever heard about the term Inversion of Control (IoC) or dependency injection but you dont know exactly what it is or why you need it then continue reading. If you have never heard about it before and you are a developer then keep on reading also! Its a really cool way of programming (design pattern) and it can help you a lot in the future and its not that difficult ūüėČ

First of all you might have heard about terms like Dependency Injection en Inversion of Control interchangeably. But there is a difference. DI is a design pattern but IoC is a mechanisme, or framework to automatically insert dependencies. Castle Windsor is for example an IoC.

Ok so what is Dependency Injection exactly. Let me give you a simple explanation:

When you go and get things out of the refrigerator for yourself, you can cause problems. You might leave the door open, you might get something Mommy or Daddy doesn’t want you to have. You might even be looking for something we don’t even have or which has expired.What you should be doing is stating a need, “I need something to drink with lunch,” and then we will make sure you have something when you sit down to eat. – John Munsch

And the main idea of an IoC framework is that if you want something you dont want to be bothered by all its dependencies. So it resolves it for you. But lets start with the design pattern.

Ok lets clarify this with a coding example. Lets say you are a person that can drive a vehicle. In that case we have a class like this:

The object Person depends on the object Car. This could be an issue if you want the person to drive a bus. You can solve this by updating the code like this:

Now you inject the dependency when initializing the object Person. As long as the object Bus implements the interface IVehicle this person can drive it. Implementing a dependency like this is called the Dependency Injection design pattern.

But this pattern still has some issues. You have to initialize a Vehicle before you can create a new Person. But the vehicle can depend again on another dependency B which can depend on another dependency C. So before you can create a person you have to initialize object C, then initialize B and insert C then initialize a vehicle and insert B and then you can initialize a Person by inserting a vehicle object. Can you see the issue with this?

One way to solve this is using the Factory design pattern. With this pattern you create a static factory class that resolves all dependencies. So if you need a new Person all you do is:

Factory is a static method that could look like this:

But now imagine that object B is changed and no longer depends on C but on an object D. That causes problems here because the factory method no longer works. You have to remember to update the factory method of object Person.

You can solve this by creating a factory method for every object. Your person factory method would look then like this:

The Bus Factory method will call the B Object Factory method etc. But creating all these factory methods and maintaining them can also be an issue or something that you dont want to be bothered with. In that case it could be a good idea to use a IoC framework like Castle Windsor that does all the work for you.

Castle Windsor

Inversion of Control (called IoC) frameworks are different from all other kinds of frameworks in that you don’t see many calls to the framework in your code. In fact – in most applications (regardless of their size and complexity) you will only call the container directly in three places. That’s the most common pattern of usage and Windsor supports it fully.

Before I continue understand that there is a difference between Inversion of Control and a Inversion of Control Container.

Inversion of Control

Inversion of Control is a principle used by frameworks as a way to allow developers to extend the framework or create applications using it. The basic idea is that the framework is aware of the programmer’s objects and makes invocations on them.

This is the opposite of using an API, where the developer’s code makes the invocations to the API code. Hence, frameworks invert the control: it is not the developer code that is in charge, instead the framework makes the calls based on some stimulus.

You have probably been in situations where you have developed under the light of this principle, even though you were not aware of it.

Inversion of Control Container

An Inversion of Control Container uses the principle stated above to (in a nutshell) manage classes. That is, their creation, destruction, lifetime, configuration, and dependencies. This way classes do not need to obtain and configure the classes they depend on. This dramatically reduces coupling in a system and, as a consequence, simplifies reuse and testability.

There is some confusion created by people that think that ‘Inversion of Control’ is a synonym for ‘Inversion of Control Container’. As stated, Inversion of control is a broader principle.

Example using Castle Windsor

Start with creating a new empty project and add a reference to Castle Windsor using the NuGet package manager.

Castle Windsor

Installing Castle Windsor from NuGet Package Manager

For this example I am using a simple Console Application. But Castle Windsor can be used in any C# application. I start with an empty application:

Furthermore I created a component with some dependencies:

What I like to do now is create a new instance of the component Rowan with the help of Castle Windsor.

  1. First create a Castle Windsor container. The preferred location for initiating Castle Windsor is in the entry project. Meaning put it in case of an MVC project in global.asax.cs (Application_Start) and in case of an application in your Program.Main.
  2. Now add an installer. Castle Windsor can automatically find installers in your project when the installer implements the IWindsorInstaller interface. If you want Castle Windsor to run all installers in your assembly use:
  3. Somewhere in your application define a installer. An installer registers classes with Castle Windsor so that Windsor can resolve them later. An example of an installer:

    Notice the pick() which is very important because otherwise nothing will be registred. In this example we register every class with all interfaces . You can also be very specific like this:

    In the above code we only register class Rowan and we are very specific to which class should be used when asked for an interface IDependency.
    Normally you only register root components. All other components are automatically resolved when you initiate the root component. In MVC such root components are for example the controllers. So an example of a installer for an MVC project could be:
  4. Now you are ready to use all your classes without having to worry about their dependencies. To use the class Rowan which depends on the dependencies IDependency1 and IDependency2 you use Castle Windsor Resolve method:
  5. Last dont forget to dispose of all your objects by calling container.Dispose(). Put this in your Application_End for example.

These are just the very basics of Castle Windsor. The framework is very powerfull and has many configuration options. Just remember that Castle Windsor is using the Three Calls Pattern (RRR) and that everything is based on Registering, Resolving and then Releasing.

TIP! Read the Basic Windsor Tutorial if you are planning on using Castle Windsor. Its really good and explains a lot like how to use Castle Windsor in MVC projects and how to replace your DefaultControllerFactory in your MVC with WindsorControllerFactory.

More information


  1. Hi,

    This post is really useful to understand and implement the basics of IoC -> Di as well could you help me to implement the same using the config files, ie bringing the name(id), service(interface), type (classes) in the app.config or web.config.


Leave a Comment.