Ninject vs Unity pour DI

Question

Nous utilisons ASP.net MVC.

Lequel de ces modèles est le meilleur framework DI de Ninject ou Unity et pourquoi?

Answer 1

La dernière fois que j'ai regardé l'un ou l'autre, j'ai trouvé Ninject un peu mieux. Mais les deux ont leurs inconvénients.

Ninject a un meilleur schéma de configuration fluide. Unity semble s'appuyer principalement sur la configuration XML. L'inconvénient principal de Ninject est qu'il vous oblige à référencer Ninject.Core partout dans votre code pour ajouter des attributs [Inject].

Si je puis me permettre, pourquoi limitez-vous vos choix à ces deux-là? Je pense que Castle.Windsor, Autofac et StructureMap sont au moins aussi bons ou meilleurs.

Answer 2

Je sais que c'est une vieille question, mais voici mes réflexions:

Personnellement, j'aime Ninject. J'aime la fluidité des interfaces et en évitant de XML. De manière générale, j'aime XML, tout simplement pas pour ce genre de config choses. Surtout quand le refactoring est impliqué, la fluidité des interfaces de le rendre plus facile à corriger.

Je m'ennuie de StructureMap de ObjectFactory, mais il existe des solutions de contournement facile à ajouter à Ninject.

Comme Jeffery points, vous n'avez pas à utiliser l' [Injecter] attribut lorsque vous n'avez qu'un seul constructeur.

J'ai trouvé que je préfère la fluidité des interfaces non seulement parce qu'ils éviter XML, mais parce qu'ils causent moment de la compilation des erreurs lorsque je modifie quelque chose qui les a affectés. La configuration XML qui ne fonctionne pas et le moins que je dois rappeler à modifier le mieux que je suis.

Answer 3

Ninject détecte les dépendances circulaires si vous utilisez les constructeurs d’injection, par opposition à Unity, que quelle que soit la technique d’injection, une exception StackOverflowException est extrêmement difficile à déboguer.

Answer 4

Je suis d'accord avec Mendelt, il n'y a pas de "meilleur" DI-cadre. Tout dépend de la situation et ils ont tous des avantages et des inconvénients. pense que David Hayden a dit sur DotNet Roches que l'Unité est le choix préféré si vous utilisez le reste de EntLib et sont familiers avec ce. Personnellement, j'utilise l'Unité, parce que mon client aime le fait qu'il dit Microsoft Enterprise Library (l'Unité) sur les Dll, si vous obtenez ce que je dis.

J'utilise les deux les deux de configuration xml pour configurer les interfaces et leurs implémentations concrètes, mais puis-je utiliser des attributs dans le code lors de l'injection, comme:

<type type="ILogger" mapTo="EntLibLogger">
   <lifetime type="singleton"/>
</type>

et dans le code:

[InjectionConstructor]
public Repository([Dependency] ILogger logger)

Personnellement, je pense que rend plus claire de ce qui se passe, mais bien sûr, on pourrait faire valoir que vous avez des références à l'unité de tous les dessus de votre application. Son jusqu'à vous.

Answer 5

http://www.palmmedia.de/blog/2011/8/30/ioc-container-benchmark-performance-comparison

L'unité est plus rapide mais ce n'est pas le meilleur