Ce qui est des avantages et des inconvénients de l’utilisation de Enterprise Library unité vs autres conteneurs IoC (Windsor, Spring.Net, Autofac..) ?
Réponses
Trop de publicités?Je suis en train de préparer une présentation pour un groupe d'utilisateurs. En tant que tel, je suis juste allé à travers un tas d'entre eux. À savoir: AutoFac, MEF, Ninject Spring.Net, StructureMap, d'Unité et de Windsor.
Je voulais montrer à 90% des cas (constructeur de l'injection, qui est essentiellement ce que les gens utilisent un CIO pour de toute façon). Vous pouvez vérifier la solution ici (VS2008)
En tant que tel, il ya quelques différences clés:
- Initialisation
- La récupération de l'objet
Chacun d'entre eux ont d'autres fonctions (certains ont de l'AOP, et mieux gadgets, mais en général, tout ce que je veux du CIO à faire est de créer et récupérer des objets pour moi)
Remarque: les différences entre les différentes bibliothèques de la récupération de l'objet peut être réduite à néant par l'aide de la CommonServiceLocator: http://www.codeplex.com/CommonServiceLocator
Cela nous laisse avec de l'initialisation, qui est fait de deux manières: via le code ou via XML de configuration (app.config/web.config/custom.config). Une assistance, certains prennent en charge un seul. Je tiens à noter: certains utilisent des attributs pour aider le Cio.
Voici donc mon évaluation des différences:
Ninject
Code d'initialisation (avec attributs). J'espère que vous aimez les lambdas. L'initialisation du code 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 d'Attributs. v2.5 est également très lambda n'. Dans l'ensemble, c'est un de mes favoris. Des idées très intéressantes autour de la façon dont StructureMap utilise des 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>();
});
L'unité
Code d'initialisation et XML. Belle bibliothèque, mais de configuration XML est une douleur dans le cul. Grande bibliothèque de Microsoft ou de l'autoroute, des commerces. Code d'initialisation est facile:
container.RegisterType<ICustomerRepository, CustomerRepository>()
.RegisterType<ICustomerService, CustomerService>();
Spring.NET
XML seulement aussi loin que je peux dire. Mais pour la fonctionnalité Spring.Net ne tout sous le soleil que le Cio peut faire. Mais parce que la seule façon de unitize est via un fichier XML, il est généralement évitée par .net magasins. Bien que de nombreux .net/Java utilisation en atelier Spring.Net en raison de la similitude entre les .la version net de Spring.Net et la Java projet pour le Printemps.
Remarque: la Configuration dans le code est désormais possible avec l'introduction de Spring.NET CodeConfig.
Windsor
XML et le code. Comme Spring.Net à Windsor, va faire tout ce que vous voulez qu'il fasse. Windsor est probablement l'un des plus populaires du Cio contenants.
IWindsorContainer container = new WindsorContainer();
container.AddComponentWithLifestyle<ICustomerRepository, CustomerRepository>("CustomerRepository", LifestyleType.Singleton);
container.AddComponentWithLifestyle<ICustomerService, CustomerService>("CustomerService",LifestyleType.Singleton);
container.AddComponent<Form1>("Form1");
Autofac
Peut mélanger les deux XML et le code (avec v1.2). Simple et agréable, la bibliothèque du Cio. Semble à la base avec pas beaucoup de bruit. Prend en charge les conteneurs imbriqués avec local de délimitation de l'étendue de composants et bien définie de la vie-la gestion du temps.
Voici comment vous devez l'initialiser:
var builder = new ContainerBuilder();
builder.Register<CustomerRepository>()
.As<ICustomerRepository>()
.ContainerScoped();
builder.Register<CustomerService>()
.As<ICustomerService>()
.ContainerScoped();
builder.Register<Form1>();
Si j'avais à choisir aujourd'hui: je serais probablement aller avec StructureMap. Il a le meilleur support pour C# 3.0 fonctions du langage, et plus de flexibilité lors de l'initialisation.
Note: Chris Brandsma tourna la réponse originale à cette question dans un billet de blog.
Autant que j'en ai vu, ils sont à peu près la même, sauf pour quelques détails de mise en œuvre ici et là. Le plus grand avantage que l'Unité a la plus de la concurrence est qu'il est fourni par Microsoft, il ya beaucoup d'entreprises là-bas qui ont peur de l'OSS.
Un inconvénient est que c'est assez nouveau donc il peut avoir des bugs que les joueurs plus âgés ont déjà triés.
Cela dit, vous pouvez vérifier cela.
Vieux thread mais puisque c'est la première chose que Google m'a montré quand j'ai tapé dans l'unité vs spring.net...
Le printemps ne faire CodeConfig maintenant, si vous n'aimez pas de configuration XML
http://www.springframework.net/codeconfig/doc-latest/reference/html/
Aussi, le Printemps est beaucoup plus que juste un conteneur d'injection de dépendances, si vous regardez les "Modules" de la section " docs, le conteneur d'injection de dépendances est à la base de l'énorme pile de choses qu'il fait.
Le printemps est une fonctionnalité qu'il peut injecter des paramètres au constructeur ou bien, en s'appuyant sur le nom du paramètre ou de la position. Ceci est très utile si le paramètre ou de la propriété est de type simple (par exemple, un entier, un booléen). Voir l'exemple ici. Je ne pense pas que ce qui fait vraiment pour le Printemps de l'impossibilité de faire de la config dans le code.
Windsor peut aussi le faire, et peut le faire dans le code non config. (corrigez-moi si je me trompe, je vais juste par ce que j'ai entendu ici).
Je voudrais savoir si l'Unité ne peut le faire.