Enterprise Library Unidade vs Outros IoC Containers [fechado]

Question

O que é prós e contras do uso de Enterprise Library Unidade vs outros recipientes de IoC (Windsor, Spring.Net, Autofac ..)?

Answer 1

Estou preparando uma apresentação para um grupo de usuários. Como tal, eu só passei um monte deles. A saber:. Autofac, MEF, Ninject, Spring.Net, StructureMap, Unidade, e Windsor

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

Como tal, existem algumas diferenças fundamentais:

• A inicialização
• Objeto de recuperação

Cada um deles tem outras características, bem como (alguns têm AOP, e melhores aparelhos, mas geralmente tudo que eu quero uma COI a fazer é criar e recuperar objetos para mim)

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

Isso nos deixa com a inicialização, que é feito de duas maneiras: por meio de código ou através de configuração XML (app.config / web.config / custom.config). Algum apoio tanto, apenas um pouco de apoio. Devo observar:. Atributos algum uso para ajudar o COI junto

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

Ninject

inicialização

Código única (com atributos). Espero que gostem lambdas. Inicialização olhares código como este:

 IKernel kernel = new StandardKernel(
                new InlineModule(
                    x => x.Bind<ICustomerRepository>().To<CustomerRepository>(),
                    x => x.Bind<ICustomerService>().To<CustomerService>(),
                    x => x.Bind<Form1>().ToSelf()
                    ));

StructureMap

código de inicialização ou XML ou atributos. v2.5 é também muito lambda'y. Tudo somado, este é um dos meus favoritos. Algumas idéias muito interessantes em torno de como StructureMap usa atributos.

ObjectFactory.Initialize(x =>
{
    x.UseDefaultStructureMapConfigFile = false;
    x.ForRequestedType<ICustomerRepository>()
        .TheDefaultIsConcreteType<CustomerRepository>()
        .CacheBy(InstanceScope.Singleton);

    x.ForRequestedType<ICustomerService>()
        .TheDefaultIsConcreteType<CustomerService>()
        .CacheBy(InstanceScope.Singleton);

    x.ForConcreteType<Form1>();
 });

Unidade

código de inicialização e XML. Biblioteca agradável, mas a configuração XML é uma dor na bunda. Grande biblioteca para Microsoft ou as lojas de rodovia. inicialização código é fácil:

 container.RegisterType<ICustomerRepository, CustomerRepository>()
          .RegisterType<ICustomerService, CustomerService>();

Spring.NET

XML apenas como perto quanto eu posso dizer. Mas para a funcionalidade Spring.Net faz tudo sob o sol que um IoC pode fazer. Mas porque a única maneira para unificar é através de XML é geralmente evitada por lojas .net. Embora, muitos .net / Java loja de utilização Spring.Net por causa da semelhança entre a versão .NET da Spring.Net eo projeto Java da Primavera.

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

Windsor

XML e código. Como Spring.Net, Windsor fará qualquer coisa que você poderia querer que ele faça. Windsor é provavelmente um dos mais populares recipientes de IoC ao redor.

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

Autofac

Pode misturar XML e código (com v1.2). Agradável simples biblioteca IoC. Parece estar a fazer o básico com não muito barulho. Suportes recipientes com escopo local de componentes e uma gestão do tempo de vida bem definido aninhados.

Aqui está como você inicializa-lo:

var builder = new ContainerBuilder();
builder.Register<CustomerRepository>()
        .As<ICustomerRepository>()
        .ContainerScoped();
builder.Register<CustomerService>()
        .As<ICustomerService>()
        .ContainerScoped();
builder.Register<Form1>();

---

Se eu tivesse que escolher hoje: eu provavelmente ir com StructureMap. Ele tem o melhor suporte para C # 3.0 recursos de linguagem, eo mais flexibilidade na inicialização.

Nota : noreferrer Chris Brandsma virou a resposta original em uma Blog Post .

Answer 2

Tanto quanto eu vi que eles são praticamente o mesmo, exceto por alguns detalhes de implementação aqui e ali. A maior vantagem que a Unidade tem sobre a concorrência é que ele é fornecido pela Microsoft, existem muitas empresas lá fora que estão com medo de OSS.

Uma desvantagem é que é bastante novo para que ele possa ter erros que os jogadores mais velhos já resolvido.

Dito isto, você pode querer verificar isso .

Answer 3

discussão antiga, mas uma vez que esta é a primeira coisa que o Google mostrou-me quando eu digitei em unidade vs spring.net ...

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

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

Além disso, a primavera é muito mais do que apenas um recipiente DI, se você olhar para a seção 'Módulos' na documentação, o contêiner DI é a base da enorme pilha de coisas que ele faz.

Answer 4

me corrija se eu estiver enganado, mas acho que em si Autofac suporta configuração XML, conforme listado neste link: Autofac XML de configuração

Answer 5

Spring tem uma característica que pode injetar parâmetros para o construtor ou propriedade com base no nome ou posição parâmetro. Isto é muito útil se o parâmetro ou propriedade é um tipo simples (por exemplo, um número inteiro, um booleano). Consulte o exemplo aqui . Eu não acho que isso realmente compensa a incapacidade da Primavera para fazer configuração no código.

Windsor também pode fazer isso, e pode fazê-lo em código não configuração. (Me corrija se eu estiver errado, eu estou indo só via o que eu ouvi aqui).

Gostaria de saber se Unity pode fazer isso.

Answer 6

Uma coisa a nota: Ninject é o único contêiner IoC que suporta injeção de dependência contextuais (como por seu website). No entanto, porque eu não tenho experiência com outros recipientes de IoC, eu não posso dizer se isso se mantém.

Answer 7

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

Answer 8

Eu pessoalmente uso Unity, mas só porque é da Microsoft. Lamento a decisão por uma razão: a coisa mais importante que tem contra ele tem uma grande "bug" que faz com que ele joga constantemente exceções. Você pode ignorar as exceções durante a depuração. No entanto, ele diminui a sua aplicação tremendamente Se você se depara-lo, uma vez que lançar uma exceção é uma operação cara. Por exemplo, eu estou atualmente "fixação" essa exceção em um ponto no meu código onde exceções da Unidade acrescenta um extra 4 segundos para uma página de tempo de render. Para mais detalhes e uma solução alternativa, consulte:

Can Unity ser feita para não jogar SynchronizationLockException o tempo todo?