Bibliothèque d'entreprise Unity vs autres conteneurs IoC [fermé]

Question

Quels sont les avantages et les inconvénients de l'utilisation de Enterprise Library Unity par rapport à d'autres conteneurs IoC (Windsor, Spring.Net, Autofac ..)?

Answer 1

Je prépare une présentation pour un groupe d'utilisateurs. En tant que tel, je viens de passer par un tas d'entre eux. À savoir: AutoFac, MEF, Ninject, Spring.Net, StructureMap, Unity et Windsor.

Je voulais montrer le cas des 90% (l'injection de constructeur, qui est principalement ce que les gens utilisent un CIO de toute façon). Vous pouvez consulter la solution ici (VS2008)

En tant que tel, il existe quelques différences clés:

• Initialisation
• Récupération d'objet

Chacune d'entre elles possède également d'autres fonctionnalités (certaines ont un AOP et de meilleurs gizmos, mais généralement tout ce que je veux qu'un CIO fasse, c'est créer et récupérer des objets pour moi)

Remarque: vous pouvez éliminer les différences entre les objets récupérés dans les bibliothèques en utilisant CommonServiceLocator: http: // www. codeplex.com/CommonServiceLocator

Cela nous laisse avec l’initialisation, qui se fait de deux manières: via code ou via configuration XML (app.config / web.config / custom.config). Certains supportent les deux, d'autres n'en supportent qu'un. Je devrais noter: certains utilisent des attributs pour aider l'IoC.

Voici donc mon évaluation des différences:

Ninject

Initialisation du code uniquement (avec attributs). J'espère que vous aimez les lambdas. Le code d'initialisation ressemble à ceci:

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

StructureMap

Code d'initialisation ou XML ou attributs. La v2.5 est aussi très lambda'y. Dans l’ensemble, c’est l’un de mes préférés. Quelques idées très intéressantes sur la façon dont StructureMap utilise les attributs.

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>();
 });

Unité

Code d'initialisation et XML. Belle bibliothèque, mais la configuration XML est pénible. Grande bibliothèque pour Microsoft ou les magasins d'autoroute. L’initialisation du code est facile:

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

Spring.NET

XML seulement aussi près que je peux dire. Mais pour la fonctionnalité, Spring.Net fait tout ce qu’un IoC peut faire sous le soleil. Mais parce que la seule façon de s'unifier est via XML, il est généralement évité par les magasins .net. Cependant, de nombreuses boutiques .net / Java utilisent Spring.Net en raison de la similitude entre la version .net de Spring.Net et le projet Java Spring.

Remarque : la configuration dans le code est désormais possible avec l'introduction de Spring.NET. CodeConfig .

Windsor

XML et code. Comme Spring.Net, Windsor fera tout ce que vous voudrez. Windsor est probablement l’un des conteneurs IoC les plus populaires.

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

Recherche automatique

Peut mélanger XML et le code (avec la version 1.2). Belle bibliothèque simple d'IoC. Semble faire les bases avec peu de tracas. Prend en charge les conteneurs imbriqués avec une portée locale des composants et une gestion de la durée de vie bien définie.

Voici comment vous l'initialisez:

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

Si je devais choisir aujourd'hui: je choisirais probablement StructureMap. Il offre la meilleure prise en charge des fonctionnalités du langage C # 3.0 et la plus grande souplesse d’initialisation.

Remarque : Chris Brandsma a transformé sa réponse initiale en article de blog .

Answer 2

D'après ce que j'ai vu, elles sont pratiquement les mêmes, à l'exception de quelques détails de mise en œuvre ici et là. Le principal avantage de Unity sur la concurrence réside dans le fait qu’il est fourni par Microsoft. De nombreuses entreprises craignent les logiciels libres.

Un inconvénient est qu’il est plutôt nouveau et qu’il peut donc contenir des bogues résolus par les anciens joueurs.

Ceci dit, vous voudrez peut-être vérifiez ceci .

Answer 3

Vieux fil, mais comme c'est la première chose que Google m'a montré quand j'ai tapé dans l'unité vs spring.net ...

Spring fait CodeConfig maintenant si vous n'aimez pas la configuration XML

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

De plus, Spring est bien plus qu'un simple conteneur DI. Si vous regardez la section "Modules" de la documentation, le conteneur DI constitue le fondement de la vaste pile de tâches qu'il produit.

Answer 4

Corrigez-moi si je me trompe, mais je pense qu'Autofac supporte lui-même la configuration XML, comme indiqué dans ce lien: Configuration XML de la saisie automatique

Answer 5

Spring a une fonctionnalité qui lui permet d’injecter des paramètres au constructeur ou à la propriété en fonction du nom ou de la position du paramètre. Ceci est très utile si le paramètre ou la propriété est un type simple (par exemple, un entier, un booléen). Voir l'exemple ici . Je ne pense pas que cela compense vraiment l'incapacité de Spring à faire la configuration en code.

Windsor peut également le faire, et peut le faire en code non config. (corrigez-moi si je me trompe, je ne fais que passer par ce que j'ai entendu ici).

J'aimerais savoir si Unity peut le faire.

Answer 6

Une chose à noter: Ninject est le seul conteneur IoC qui prend en charge les injections de dépendance contextuelle (selon leur site Web). Cependant, comme je n'ai pas d'expérience avec d'autres conteneurs IoC, je ne peux pas dire si cela tient.

Answer 7

Juste pour ajouter mes 2 centimes, j'ai essayé à la fois StructureMap et Unity. J'ai trouvé StructureMap mal documenté / mal documenté, difficile à configurer et fastidieux à utiliser. De même, il ne semble pas prendre en charge les scénarios tels que les arguments du constructeur qui surchargent au moment de la résolution, ce qui était un point d'utilisation clé pour moi. Alors je l'ai laissé tomber et je suis parti avec Unity, et je l'ai fait faire ce que je voulais en 20 minutes environ.

Answer 8

J'utilise personnellement Unity, mais uniquement parce qu'il provient de Microsoft. Je regrette la décision pour une raison: la plus grosse chose qu’elle a contre elle a un gros "bug" cela provoque constamment des exceptions. Vous pouvez ignorer les exceptions lors du débogage. Toutefois, votre application ralentit énormément si vous la rencontrez, car le lancement d'une exception est une opération coûteuse. Par exemple, je suis actuellement en train de "réparer". cette exception à un endroit de mon code où les exceptions de Unity ajoutent un supplément 4 secondes au temps de rendu d'une page. Pour plus d'informations et une solution de contournement, voir:

SynchronizationLockException tout le temps?