Qui D'Injection De Dépendance Outil Dois-Je Utiliser?
Je pense à propos de l'utilisation de Microsoft à l'Unité pour mon Injection de Dépendance dans notre Interface Utilisateur.
Notre Niveau Intermédiaire utilise déjà le Château de Windsor, mais je pense que je devrais rester avec Microsoft.
Quelqu'un a des idées sur ce que le meilleur de l'Injection de Dépendances est l'outil?
- Autofac
- Château De Micro-Noyau/Windsor
- PicoContainer.NET
- De Puzzle.NFactory
- Spring.NET
- StructureMap
- Ninject
- L'unité
- Simple Injecteur
- NauckIT.Micro-noyau
- WINTER4NET
- ObjectBuilder
- Liés à la question stackoverflow.com/questions/2216684/...
- ObjectBuilder n'est pas un DI-cadre. C'est un cadre pour la construction de DI cadres.
Vous devez vous connecter pour publier un commentaire.
Coller à un conteneur n'est pas vraiment important, si votre système a été conçu avec le Cio/DI à l'esprit. Avec la bonne approche, vous pouvez facilement changer la bibliothèque du Cio en bas de la route.
Et, bien sûr, le conteneur doit fournir suffisamment de flexibilité pour soutenir la commune largement utilisé scénarios (gestion du cycle de vie, une boîte de nidification, XML et le code de configuration, l'interception, la résolution rapide).
Je le recommande à choisir entre le Château (largement utilisés et ont beaucoup de l'intégration des bibliothèques) et Autofac (léger, rapide et a une boîte de nidification, mais n'est pas largement utilisé)
Il y a un liste complète des conteneurs IoC par, Hanselman
PS: Vous ne voulez pas utiliser l'Unité
Ayant récemment enrichi de 6 de ces (Windsor, L'unité, Spring.Net, Autofac, Ninject, StructureMap) je peux offrir un rapide résumé de chacun, nos critères de sélection et notre choix final.
Nota: nous n'avons pas les regarder PicoContainer.Net comme l'un de notre équipe considérée comme la .Port Net pour être tout à fait mauvais à partir de la version de Java. Nous avons aussi fait de ne pas regarder ObjectBuilder, comme l'Unité est construite au-dessus de ObjectBuilder2 et a été considéré comme pour être un meilleur choix par défaut.
Tout d'abord, je peux dire que plus ou moins tous d'entre eux sont tous assez semblables et il vient vraiment à ce qui fonctionne le mieux pour vous, et à vos exigences spécifiques. Nos exigences:
Exigences
ILogger -> typeof(FileLogger)ouILogger -> new FileLogger())IDisposablecomposants sur le conteneur abattrebien documenté et/ou d'information en ligne facilement disponibles
Remarque: bien que la performance a été une exigence, il n'a pas été pris en compte dans la sélection car il semblait que tous les récipients examinés étaient similaires selon cette référence
Test
Chaque conteneur a été utilisé dans un cadre typique Asp.Net webforms projet (ce qui était notre objectif type d'application). Nous avons utilisé une simple page avec un simple contrôle de l'utilisateur, chaque héritage d'une page de base /de contrôle de base, respectivement. Nous avons utilisé 1 conteneur sur le
BasePagepour un "par la demande" champ d'application conteneur et 1 sur le global.asax pour une "application" de la portée et a tenté de la chaîne d'ensemble afin d'dépendances pourrait être résolu à partir de deux récipients.Chaque application web partagé artificiel, ensemble d'objets du domaine la simulation multi-niveaux de dépendance, type de portée (singleton/transitoire) et aussi des administrés et non administrés classes (
IDisposablenécessaire). Le "haut niveau" de la dépendance des composants ont été manuellement injecté à partir de la méthode sur leBasePage.Résultats
Windsor - Satisfait à tous les critères et qui a une bonne histoire de cas, communauté de blogueurs et de documentation en ligne. Facile à utiliser et est probablement le de facto de choix. Avancée de la création de composant par l'Usine de facilité. Également permis de chaînage de individuellement créé des conteneurs.
Spring.Net - Verbose et inutile de la documentation et de non-évident, facile pour programmable configuration. N'a pas de support pour les produits génériques. Pas choisi
Ninject - Facile à utiliser avec une bonne documentation claire. Ensemble de fonctionnalités puissantes s'acquitter de l'ensemble de nos exigences, sauf conteneur des hiérarchies donc, malheureusement, n'a pas été choisi.
StructureMap - Mal documentée, bien que j'avais tout un ensemble de fonctionnalités avancées qui répondent à tous nos besoins, mais il n'y avait pas de mécanisme intégré pour le conteneur des hiérarchies qu'il pouvait être réalisé à l'aide de boucles de voir ici L'expression lambda interface fluide a semblé un peu plus compliqué au premier abord, bien qu'ils puissent être encapsulé loin.
L'unité - Bien documenté, facile à utiliser et répondait à tous nos critères de sélection et a un simple mécanisme d'extension pour ajouter des pré/post création de concours complet mécanisme que nous avons besoin. Conteneurs enfant a dû être créé à partir d'un conteneur parent.
Autofac - Bien documenté et relativement facile à utiliser, même si la lambda expression de configuration ne semble un peu plus compliqué mais, encore une fois, peut être facilement encapsulé à l'écart. Composant de la portée est atteint grâce à un "marquage" mécanisme et tous les composants sont configurés à l'avant à l'aide d'un générateur qui était un peu gênant. Enfant conteneurs ont été créés à partir d'un parent et affectés à des composants à partir d'un "tag". Permis générique injection.
Conclusion
Notre choix final a été entre Windsor et de l'Unité, et cette fois-ci nous avons choisi de l'Unité en raison de sa facilité d'utilisation, la documentation, le système d'extension et, avec elle, d'être dans la "production" de statut de.
Voici un bon article qui compare .NET Cio conteneurs.
http://blog.ashmind.com/index.php/2008/08/19/comparing-net-di-ioc-frameworks-part-1/
J'ai commencé à utiliser Autofac il y a un an et je n'ai pas regardé en arrière depuis..
Je suis un Autofac fan, mais Windsor et l'Unité sera de faire un bon travail (bien que Windsor est plus capable que de l'unité et ne nécessite pas d'attribution de votre code). Il y a beaucoup de bonne technique non des raisons pour s'en tenir à un seul récipient dans un système si.
Utiliser ce qui fonctionne. La plupart ont des caractéristiques qui sont uniques à eux, et presque tous sont plus riche en fonctionnalités que l'Unité. Si l'unité est tout que vous avez besoin, vous pouvez certainement l'utiliser.
À l'aide de Microsoft à l'unité juste parce que c'est à partir de Microsoft est une mauvaise façon de prendre une décision. Pensez à ce que vous avez besoin et pourquoi, et choisissez celui qui correspond à vos besoins.
Cependant, je seconde l'idée de s'en tenir à un seul conteneur, si possible.
J'ai été en utilisant le Managed Extensibility Framework et trouvé ça assez facile de travailler avec. Il a été intégré dans .NET 4.
https://stackoverflow.com/questions/71041/which-single-iocdi-container-would-you-recommend-using-and-why
Sauf si vous avez déjà une expérience et un personnel de choix pour un sous-technologie utilisée par l'un des conteneur IoC solutions, ils fonctionnent tous bien, et je ne vois pas un en particulier avec un "tueur de fonction" qui permet de se démarquer des autres. L'unité est probablement le meilleur ajustement pour les solutions déjà utilisé le P&P Bibliothèque d'Entreprise 4.x...
Conteneur IoC de Référence - comparaison des Performances a des performances et des caractéristiques des tableaux de comparaison pour les+ de 20 produits et de les garder à jour.
La conclusion de l'article: