Unity vs Castle Windsor

Recently I did a post on breaking dependencies which used the Castle Windsor container as the Inversion of Control container.  I thought I'd also have a look at doing the same thing with the Unity container from Microsoft's Patterns & Practices team, which was version 1.0'ed last month.

The good news?  It's pretty much just some slight syntax changes and that's about it.  The only problem I found was that after installing the Unity help file for VS2008 my Visual Studio help is now broken and now I have to go and repair my Visual Studio installation.  I'd suggest sticking to the CHM file instead.

Here's the only differences between the two applications:

1. References (duh!)

Castle Windsor

using Castle.Windsor;
using Castle.Core.Resource;
using Castle.Windsor.Configuration.Interpreters;

Unity

using System.Configuration;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;

2. Instantiating the Container

Castle Windsor

            IWindsorContainer container = new WindsorContainer(new XmlInterpreter());

Unity

            IUnityContainer container = new UnityContainer();

            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.Configure(container);

3. The .config files

Castle Windsor

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="castle" type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" />
    </configSections>

    <castle>
        <components>
            <component id="prompt.input" service="SalesPrompter.IInputControl, SalesPrompter"
                type="SalesPrompter.PromptInputControl, SalesPrompter" />
            <component id="console.display" service="SalesTax.IMessageDisplay, SalesTax"
                type="SalesTax.ConsoleMessageDisplay, SalesTax" />
            <component id="input.parser" service="SalesTax.IInputParser, SalesTax"
                type="SalesTax.InputParser, SalesTax" />
            <component id="salelinefactory" service="SalesTax.ISaleLineFactory, SalesTax"
                type="SalesTax.SaleLineFactory, SalesTax" />
        </components>
    </castle>

</configuration>

Unity

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="unity"  type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection, Microsoft.Practices.Unity.Configuration" />
    </configSections>

    <unity>
        <typeAliases></typeAliases>
        <containers>
            <container>
                <types>
                    <type type="SalesPrompter.IInputControl, SalesPrompter" 
                        mapTo="SalesPrompter.PromptInputControl, SalesPrompter"/>
                    <type type="SalesTax.IMessageDisplay, SalesTax" 
                        mapTo="SalesTax.ConsoleMessageDisplay, SalesTax"/>
                    <type type="SalesTax.IInputParser, SalesTax" 
                        mapTo="SalesTax.InputParser, SalesTax"/>
                    <type type="SalesTax.ISaleLineFactory, SalesTax" 
                        mapTo="SalesTax.SaleLineFactory, SalesTax"/>
                </types>
            </container>
        </containers>
    </unity>

</configuration>

Note that there was nothing different in the resolving of references.  Both containers have a Resolve<T>() method that does exactly the same thing.

So, how easy is that? :-)  The P&P team have done a pretty good job with this container.  Admittedly I haven't really looked into some of the more advanced options, but it looks quite good and being from the P&P team it's likely to get more traction that the Castle Windsor container in the corporate development world.