Je suis sûr que je suis quelque peu perdu dans cette zone ... Je crois comprendre que l'injection de dépendance signifie initialiser quelque chose qui est requis par une classe..so par exemple.
Si mon contrôleur va avoir besoin d'un service et que je veux pouvoir le tester, je devrais définir deux méthodes de constructeur pour cela ... Donc, ma question est ... pourquoi les gens utilisent-ils des frameworks pour y parvenir ?? Im perdu
7 Réponses :
Les gens n'utilisent pas un cadre d'injection de dépendance pour générer le code que vous avez fourni dans votre exemple. C'est toujours le travail du développeur.
Le cadre d'injection de dépendance est utilisé lorsque quelqu'un appelle le constructeur. Le cadre injectera la mise en œuvre concrète de l'icompaniesservice plutôt que le développeur appelant explicitement le constructeur.
S'il s'agit d'un produit spécifique, le NIJJECT HOMEPAGE a réellement de très bons exemples.
wiki.github.com/ninject/ninject/dependency-Injection-by- Main Je suis à peu près sûr que mon code est un exemple d'injection de dépendance à la main .. Donc les cadres fournissent un moyen d'implémenter automatiquement une injection de dépendance
Une raison majeure consiste à mieux soutenir le test de l'unité et la moqueur d'objets pour créer des tests contrôlés.
En ne spécifiant pas la mise en œuvre à l'intérieur de la classe, vous pouvez "injecter" une implémentation au moment de l'exécution. (Dans votre exemple, l'interface Icompaniesservice).
au moment de l'exécution, à l'aide d'une inversion de conteneur d'injection de contrôle / dépendance telle que StructureMap, Unity ou Castle Windsor, vous pouvez dire "Hey, à tout moment, quelqu'un veut une instance d'ICompanIESService leur donner un nouvel objet SomponService".
Pour tester un appareil à tester cette classe, vous pouvez vous moquer de notre icompaniesservice et leur fournir vous-même au constructeur. Cela vous permet de configurer des méthodes contrôlées sur l'objet simulé. Si vous ne pouviez pas faire cela, vos tests de l'unité pour les entreprisesController seraient limités à l'utilisation de la seule mise en œuvre du service de votre entreprise, ce qui pourrait frapper une base de données en direct, etc., rendre votre unité teste à la fois lente et incohérente.
L'applicabilité de l'injection de dépendance à des tests unitaires est un effet secondaire agréable. Une raison plus "majeure" est de supporter des applications couplées de manière lâche.
de Wikipedia :
sans le concept de dépendance injection, un consommateur qui a besoin d'un service particulier
"icompaniesservice" afin de accomplir une certaine tâche serait responsable de la manipulation de la cycle de vie (instanciation, ouverture et des flux de fermeture, disposer, etc.) de ce service. En utilisant le concept de Injection de dépendance, cependant, la cycle de vie d'un service est géré par une dépendance fournisseur / cadre (typiquement a conteneur) plutôt que le consommateur. Le consommateur n'aurait donc besoin que d'un référence à une mise en œuvre du service "icompaniesservice" qu'il avait besoin pour accomplir la tâche nécessaire. Lisez celui-ci aussi:
Les gens utilisent des cadres d'injection de dépendance, car sinon, vous devez écrire une tonne métrique de classes d'usine épanouie et répétitives (si vous utilisez une injection de dépendance, c'est-à-dire).
Cela peut être fait, c'est juste très, très gênant.
Je pense que votre compréhension n'est que partiellement correcte. L'injection de dépendance est "injectable" une dépendance d'un composant en elle. C'est une forme plus spécifique d'inversion de contrôle. Pendant Ce processus Certaines dépendances peuvent également être initialisées avant d'injecter.
avec DI, l'ONUS de la recherche de la dépendance n'est pas sur le composant (comme dans le motif de serviceloacator) mais jusqu'à ce que le conteneur dans lequel le composant est fonctionnement. Le modèle a suivi des avantages:
Dans votre exemple de code, une dépendance peut être injectée par un conteneur DI au moment de l'exécution via la seconde. constructeur. D'autres formes d'injections sont également possibles (selon le conteneur DI). par exemple. Injection de champ, injection de setter, etc.
Il y a un Bon article par Martin Fowler qui a inventé le di Terme
Vous n'avez pas besoin d'avoir un cadre DI, mais à un moment donné de votre codeBase, une implémentation concrète devra être instanciée et injectée dans vos constructeurs / propriétés. Cela peut devenir très désordonné si vous n'avez pas de di-cadre, je vous recommande de regarder le château Windsor bien que mentionné, il y en a d'autres qui effectueront les mêmes fonctionnalités. Ou si vous pouviez Rôle de votre propre .... :)
Je vais lancer dans:
Vous pouvez accomplir une injection de dépendance simplement en ayant une définition de fonction paramétrée.
Cependant, afin de faire ce travail de manière cohérente, tout le monde doit réellement faire cela. Beaucoup trouvent que c'est plus facile de faire respecter la Convention en utilisant un modèle de conception d'usine.
Les cadres d'injection de dépendance résolvent le problème de la réduction de la chaudière de l'écriture de ces usines.
Je dirais que l'injection de dépendance à travers une usine n'est pas idéale. Dans mes usines d'opinion, ajoutez une couche supplémentaire d'indirection et, dans un sens, faites des fonctions déterministes dans le sens où elles sont maintenant une fonction des entrées, ainsi que l'état du reste du programme (votre configuration DI) que vous ne pouvez pas voir de la définition de la fonction seule. Les usines rendent le code plus difficile car ils ajoutent une couche supplémentaire d'indirection, je dirais que dans de nombreux cas, il n'est vraiment pas trop difficile de suivre la Convention et d'injecter manuellement des cours via les arguments de la fonction. Encore une fois, pour une grande base de code, il est probablement plus facile d'appliquer la règle à travers une usine.
.. Cela étant dit parfois que je me demande si ces grandes basses basses constitueraient même si elles n'écrivaient pas autant de choses qui tentent de résoudre de manière préemptive de résoudre les problèmes qu'ils n'ont pas en premier lieu.