J'aimerais essayer d'utiliser un cadre DI / COO pour la première fois dans un projet de petite ish, mais je ne veux pas perturber beaucoup le projet en introduisant des dépendances volumineuses. Le projet lui-même est en partie destiné à être utilisé comme bibliothèque d'autres projets et je ne veux pas déranger les utilisateurs à gérer des dépendances supplémentaires. C'est aussi une question de goût - je sens que la taille d'une composante devrait être proportionnelle au nombre de services que j'ai réellement besoin. Je déteste incorporer une composante volumineuse avec des dépendances à part entière, seulement pour en utiliser une petite partie de celui-ci.
Donc, pour .NET, existe-t-il un petit cadre DI / IOO qui compile une DLL unique sans dépendances autres que les bibliothèques standard, que (si nécessaire) pourraient être directement intégrées à l'assemblage qui l'utilise et qui souligne Câblage basé sur le code / fluide (par opposition au XML)? Il ne doit pas nécessiter .NET Framework 4.0.
7 Réponses :
Jetez un coup d'œil à NIJJECT .
Le téléchargement de .NET Framework 3.5 sur Ninject.org/download contient 6 dlls supérieures à la moitié de MEG, plus lourd que j'étais Espérer que.
Tout ce que vous référence dans votre projet est l'ensemble ninject.dll unique qui répond à vos critères légers. Il existe une série d'assemblages d'extensions et de web.mvc additifs à la fonctionnalité Ninject de base si vous en avez besoin.
Ces assemblées sont-elles facultatives, ou NInject.dll les nécessite-t-elle? Le fichier XML est-il requis?
Facultatif, XML non requis. Ninject est léger et non intrusif.
Oui, tous les autres assemblages sont facultatifs.
Ah bien. Ninject.dll elle-même n'est que 94 kb que je suis à l'aise avec.
Accepté - les principes de conception chez wiki.github.com/ninject/ninject sont très attrayants et Je suis une ventouse pour le site Web slick.
Inaccepté - la documentation est dans un état désordonné (et en regardant le code source n'aide pas sans connaître les concepts ... je suis perdu dans une toile de "liaisons", "composants", "noyaux", "planificateurs", "planificateurs" et "paramètres"). De plus...
... de plus, c'est lent. Compte tenu d'une interface "inothémique" vide, une classe "Rien" et une liaison triviale, une boucle serrée qui appelle kernel.get
Je me sens beaucoup la même chose que vous le faites sur les cadres de la COI. J'utilise tout le temps du CIO, je ne vois tout simplement pas le besoin d'un cadre.
Cela dit, celui que j'utiliserais si je devais choisir un up serait Autofac < / a>
C'est simple, facile à saisir et se sent léger.
nblumhardt.com/2010/04/introducing-autofac-2-1 -rtw - dit "Autofac utilise le support sous-jacent dans .NET 4.0"
A droite, Autofac 2.1 fait. Mais les versions avant que (1.4) n'ont pas besoin de 4.0. Si vous déployez une application 4.0, le fait qu'il utilise le matériel .NET sous-jacent est une bonne chose :)
Je suis limité à VS 2008 et, en plus, je ne veux pas obliger les utilisateurs à mettre à niveau leur .NET FRAMWork. Il semble qu'il existe une version .NET 3.5 de Autofac 2.2, mais il est livré avec 5 dlls et un fichier XML plus grand que les 5 dlls combinés, je me demande combien de cela est nécessaire?
Je viens de remarquer que Ninject et Autofac ont des fichiers XML beaucoup plus grands que leur dll principale .... Edit: haha! Je vois que les fichiers XML contiennent juste de la documentation. Donc, ils ne sont pas réellement nécessaires au moment de l'exécution, de bonnes nouvelles.
Vous avez seulement besoin de Autofac.dll, et cela fonctionne totalement avec .NET 3.5
Je suis convaincu que l'autofac est la voie à suivre. Il est conçu spécifiquement pour qu'aucun de votre code n'en dépense, à l'exception de cet endroit où vous "filez tout." Vous pouvez concevoir votre programme avec Autofac à l'esprit, mais ne pas "ajouter de référence" jusqu'à ce que votre projet soit suffisamment grand que le câblage manuel est une douleur.
Je suggérerais également en plus de NIJJECT que vous regardez Microsoft's Di Framework , Unity .
Je travaille avec un système plutôt volumineux et nous avons tout injecté manuellement. Nous utilisons le modèle d'usine abstrait pour ranger la majeure partie de l'injection / le câblage et cela est bien terminé.
DI Frameworks sont abondants. Avant de prendre une dépendance externe supplémentaire, prenez le temps de considérer si l'application d'un modèle différent / nouveau résoudrait vos problèmes.
Modifier: (éventuellement biaisé / injuste) raisons pour lesquelles je n'ai pas utilisé de DI Cadre:
Quant à la construction de cette usine, la plupart des outils de refactorisation peuvent faire 90% du travail pour vous avec très peu de frappes de frappe.
Avez-vous réellement utilisé un cadre DI? Si oui, avez-vous trouvé que c'était plus de problèmes que cela vaut la peine?
Je ne vois pas comment l'injection manuelle dans un grand système est moins de travail que de le faire effectuer automatiquement à l'aide d'un cadre DI.
La réponse était un peu longue pour un commentaire, édité ma réponse à la place.
Tout cadre que vous introduirez sera éventuellement une dépendance de votre application. De plus, les gens ont des définitions variées de ce que la légère mesure est légère. Jetez un coup d'œil à UNITY ou StructureMap ou château Windsor alors qu'ils ont tendance à être plus populaires. Scott Hanselman a une liste complète, ici . Prenez votre choix.
+1 pour la liste. Techniquement, si j'intégrais le conteneur IOC dans l'une de mes DLL et modifiez l'espace de noms, cela ne ressemblera pas à une dépendance de l'extérieur, plus j'avais la possibilité de supprimer tout ce que je n'utilise pas. Compte tenu de la façon dont ils expliquent sa conception, je pense que le microkernel de Windsor est agréable à cette approche ...
@Qwertie au bas de la poste de Hanselman référencé est un lien vers deux conteneurs de COI dans 15 lignes de codes. Leur but est d'être extrêmement léger lorsque vous n'avez pas besoin d'un "cadre". Peut-être que ça vaut la peine d'être examiné.
Il y a Exemples sur le Web sur la rédaction de votre propre conteneur, bien qu'ils soient très basiques et manquent de fonctionnalités fournies par un cadre plus robuste.
Vous n'avez pas besoin d'une bibliothèque si vous souhaitez simplement inversion de contrôle. Il suffit d'injecter vos dépendances à travers le constructeur de votre classe.
En ce moment c'est ce que je fais. Cependant, les choses de câblage commencent à devenir légèrement encombrantes et je sais que cela s'aggravera au fur et à mesure que le projet grandit. (C'est un projet de compilateur composé de nombreux composants et il devrait être possible d'échanger des composants pour les autres ...)
Je suis d'accord avec Robert. En injectant des dépendances dans le code, vous bénéficiez également du compilateur. Je filme généralement ma demande dans la méthode principale ().