Working with Interfaces Part Three – Windsor

Castle Windsor is an Inversion of Control container which uses interfaces as a key concept. When working in the manner I described in my previous articles on interfaces, you get a decoupled application but may end up with a lot of “wiring-up” – instantiating interface implementations then passing them into your classes.

For example, a Controller may often demand an implementation of ILogger, IAuthenticationService, IRepository and IPaymentGateway, which would require a fair bit of code to wire up. Windsor removes the wire up burden from the developer. Using XML configuration, you can easily swap out one implementation for another:

public interface ISport{}<br>public class Football : ISport{}<br><br><component id=""<br>	service="ISport, WindsorTest"<br>	type="Football, WindsorTest"/>

In this example, we use the component element to wire up the Football implementation for any usage of ISport. For Windsor to provide this ISport implementation to your consuming classes, the consumer needs to be in the container too:

public class Consumer<br>{<br>	// Parameter injection<br>	public ISport Sport{ get; set; }<br>	// Constructor injection<br>	public Consumer(ISport sport){} <br>}<br><br><component id="some.consumer" type="Consumer, WindsorTest"/>

So now Consumer will have the configured ISport passed to its constructor or the Sport parameter, depending on your preference. We could also have an ISport parameter on Consumer and Windsor would be able to set it with the configured implementation of ISport.

Using a system like Windsor is a logical extension of the practises I’ve talked about before. It gives you the flexibility of interfaces without the burden of having to manually instantiate and pass through all of the implementations your classes may depend upon. When thinking about Domain Driven Design, you can use Windsor to provide Services to your application, allowing it to consume independent components and create one awesome whole. Full Windsor documentation can be found on the Castle website, and I’ve also written about Windsor on my personal blog.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

8 Responses to Working with Interfaces Part Three – Windsor

  1. cramsay says:

    Many, many thanks to Sean for editing this article for me.

  2. Good post Colin! keep it up!

  3. When you say football, you mean American Soccer, right? ;)

    Great post Colin. Keep’em coming.

    Nice picture of the (w)hole.

  4. Joe Ocampo says:

    How does windsor differentiate between constructor injection and property injection?

  5. cramsay says:

    joe: Do you mean setting up a property for one ISport implementation and the constructor for another? If so… I’m not sure!

  6. @Joe at runtime, when windsor constructs a component it checks the constructor arguments for other components that it can supply. Once the class constructor is called, windsor scans properties for components and then injects them into the class.

    This is my understanding at least. The actual process that windsor takes might be different.

    is that what you mean?

  7. Joe Ocampo says:

    Yes, that is exactly what I was asking about. I was worried about implicit injection but I suppose this just will lead to better composition.

    Not sure if I like it but will have to think about it.

  8. Joe, you can override dependencies as well as hook into the windsor pipeline.

    I have never had a need but if you check out the castleproject forum as well as the dev list they talk about it frequently there.