Enterprise Library Unity vs Outros Contêineres IoC

Quais são os prós e contras de usar o Enterprise Library Unity em comparação com outros contêineres IoC (Windsor, Spring.Net, Autofac ..)?

    Estou preparando uma apresentação para um grupo de usuários. Como tal, eu acabei de passar por um monte deles. A saber: AutoFac, MEF, Ninject, Spring.Net, StructureMap, Unity e Windsor.

    Eu queria mostrar o caso de 90% (injeção de construtor, que é principalmente o que as pessoas usam um COI de qualquer maneira). Você pode verificar a solução aqui (VS2008)

    Como tal, existem algumas diferenças fundamentais:

    • Inicialização
    • Recuperação de Objetos

    Cada um deles tem outros resources também (alguns têm AOP e melhor gizmos, mas geralmente tudo que eu quero que um COI faça é criar e recuperar objects para mim)

    Nota: as diferenças entre a recuperação de objects de bibliotecas diferentes podem ser negadas usando o CommonServiceLocator: http://www.codeplex.com/CommonServiceLocator

    Isso nos deixa com a boot, que é feita de duas maneiras: via código ou via configuração XML (app.config / web.config / custom.config). Alguns suportam ambos, alguns suportam apenas um. Devo observar: alguns usam atributos para ajudar o IoC.

    Então, aqui está minha avaliação das diferenças:

    Ninject

    Apenas boot de código (com atributos). Espero que você goste de lambdas. O código de boot é assim:

    IKernel kernel = new StandardKernel( new InlineModule( x => x.Bind().To(), x => x.Bind().To(), x => x.Bind().ToSelf() )); 

    StructureMap

    Código de boot ou XML ou atributos. v2.5 também é muito lambda’y. Tudo sumdo, este é um dos meus favoritos. Algumas idéias muito interessantes sobre como o StructureMap usa Attributes.

     ObjectFactory.Initialize(x => { x.UseDefaultStructureMapConfigFile = false; x.ForRequestedType() .TheDefaultIsConcreteType() .CacheBy(InstanceScope.Singleton); x.ForRequestedType() .TheDefaultIsConcreteType() .CacheBy(InstanceScope.Singleton); x.ForConcreteType(); }); 

    Unidade

    Código de boot e XML. Nice biblioteca, mas a configuração XML é uma dor na bunda. Ótima biblioteca para a Microsoft ou para as lojas da estrada. A boot de código é fácil:

      container.RegisterType() .RegisterType(); 

    Spring.NET

    XML apenas o mais próximo que eu posso dizer. Mas, para funcionalidade, o Spring.Net faz tudo sob o sol que uma IoC pode fazer. Mas como a única maneira de se unificar é através do XML, isso geralmente é evitado pelas lojas .net. Embora muitas lojas .net / Java usem o Spring.Net por causa da semelhança entre a versão .net do Spring.Net e o projeto Java Spring.

    Nota : A configuração no código agora é possível com a introdução do Spring.NET CodeConfig .

    Windsor

    XML e código. Assim como o Spring.Net, Windsor fará tudo o que você quiser. Windsor é provavelmente um dos contêineres IoC mais populares da região.

     IWindsorContainer container = new WindsorContainer(); container.AddComponentWithLifestyle("CustomerRepository", LifestyleType.Singleton); container.AddComponentWithLifestyle("CustomerService",LifestyleType.Singleton); container.AddComponent("Form1"); 

    Autofac

    Pode misturar XML e código (com v1.2). Nice biblioteca IoC simples. Parece fazer o básico com não muito barulho. Suporta contêineres nesteds com escopo local de componentes e um gerenciamento de tempo de vida bem definido.

    Aqui está como você inicializa:

     var builder = new ContainerBuilder(); builder.Register() .As() .ContainerScoped(); builder.Register() .As() .ContainerScoped(); builder.Register(); 

    Se eu tivesse que escolher hoje: eu provavelmente iria com o StructureMap. Ele tem o melhor suporte para resources de linguagem C # 3.0 e a maior flexibilidade na boot.

    Nota : Chris Brandsma transformou sua resposta original em um post no blog .

    Tanto quanto eu vi eles são praticamente os mesmos, com exceção de alguns detalhes de implementação aqui e ali. A maior vantagem que a Unity tem sobre a concorrência é que ela é fornecida pela Microsoft, há muitas empresas por aí com medo do OSS.

    Uma desvantagem é que é algo novo, então pode haver bugs que os jogadores mais antigos já resolveram.

    Dito isto, você pode querer verificar isso .

    Old thread, mas desde que esta é a primeira coisa que o Google me mostrou quando eu digitei em unidade vs spring.net …

    Spring faz CodeConfig agora se você não gosta de configuração XML

    http://www.springframework.net/codeconfig/doc-latest/reference/html/

    Além disso, o Spring é muito mais do que apenas um contêiner DI, se você observar a seção ‘Módulos’ nos documentos, o contêiner DI é a base da imensa pilha de coisas que ele faz.

    Corrija-me se estiver enganado, mas acho que o próprio Autofac suporta XML Configuration, conforme listado neste link: Autofac XML Configuration

    Spring tem um recurso que pode injetar parâmetros no construtor ou na propriedade com base no nome ou na posição do parâmetro. Isso é muito útil se o parâmetro ou a propriedade for um tipo simples (por exemplo, um inteiro, um booleano). Veja o exemplo aqui . Eu não acho que isso realmente compensa a incapacidade da Spring de fazer a configuração no código.

    O Windsor também pode fazer isso, e pode fazer isso no código e não na configuração. (me corrija se eu estiver errado, só vou pelo que ouvi aqui).

    Eu gostaria de saber se a Unity pode fazer isso.

    Uma coisa a notar: Ninject é o único contêiner IoC que suporta injeções de dependência contextual (de acordo com seu site). No entanto, como não tenho experiência com outros contêineres IoC, não sei dizer se isso é válido.

    Apenas para adicionar meus 2 centavos, eu tentei o StructureMap e o Unity. Eu encontrei StructureMap para ser documentado mal / misguidingly, uma dor na bunda para configurar e desajeitado para usar. Da mesma forma, não parece suportar cenários como substituições de argumento de construtor no tempo de resolução, que era um ponto de uso chave para mim. Então eu deixei cair e fui com o Unity, e fiz o que eu queria em cerca de 20 minutos.

    Eu pessoalmente uso o Unity, mas apenas porque é da Microsoft. Lamento a decisão por uma razão: a maior coisa que tem contra ela é um grande “bug” que faz com que ele lance constantemente exceções. Você pode ignorar as exceções durante a debugging. No entanto, ele atrasa sua aplicação tremendamente se você a executar, já que lançar uma exceção é uma operação cara. Por exemplo, atualmente estou “consertando” essa exceção em um ponto no meu código onde as exceções do Unity adicionam 4 segundos extras ao tempo de renderização de uma página. Para mais detalhes e uma solução alternativa, consulte:

    Pode ser feito o Unity para não jogar SynchronizationLockException o tempo todo?