Unity vs Castle Windsor

refer:http://richardsbraindump.blogspot.com/2008/05/unity-vs-castle-windsor.html

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.

 

转载于:https://www.cnblogs.com/try/articles/1208752.html