Register Castle Windsor IOC components via convention

Favouring convention over configuration means less change points (and remember points) for developers to deal with when new code needs to be added to software. My team tries to follow this guideline as much as possible but given the fact we are new users of Castle Windsor IOC, we were not aware that we could by convention have an IXXXService implemented by the first found XXXService.

We had code like the following in our IOC bootstrapper file:


which meant of course we had to explicity update the bootstrapper file if we created a new service. A new colleague started the other day and refactored to this:


Now we only have to explicity register exceptions to the interface IXYZ being implemented by class XYZ rule. Pretty neat I thought.

We still use Castle Windsor 2, for Castle Windsor 3 I believe you need to use


One thought on “Register Castle Windsor IOC components via convention”

  1. In fact, by writing your classes this way, you can construct entire class libraries that are ignorant of Castle Windsor and will work perfectly fine with Ninject, another DI framework, or no container at all, without modifying the code. How you actually register your components (the difference between examples two and three) is partly a matter of scale.

Leave a Reply

Your email address will not be published. Required fields are marked *