May 13, 2008

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.

2 comments:

  1. Have you had a look on more complex scenarios like custom facilities, properties, auto wiring of properties and constructors, lifecycles and lifestyles?

    ReplyDelete
  2. Nice writeup but could you also give a comparison like chart of the features the both offer. I'm sure they cant both be exactly the same in all their abilities.

    ReplyDelete