Où est exactement la différence entre IoC et DI
Duplicata possible:
Inversion de contrôle <injection de dépendance
J'ai toujours lu IoC (Inversion of Control) et DI (Dependency Injection) dans le même contexte. Quelle est exactement la différence entre IoC et DI? En quoi l'IoC diffère-t-il de DI?
Dans l'usage courant, les termes sont devenus quelque peu synonymes. L'idée originale de l'IoC - Inversion de contrôle - était très liée au "Principe d'Hollywood:" Ne nous appelez pas, nous vous appellerons.
Dans les applications traditionnelles, les développeurs écrivaient du code métier et du code framework. Le code métier appelle alors le code framework pour accomplir des tâches. Dans un modèle IoC, vous "inversez" ce modèle et créez un cadre qui accepte les modules métier et les appelle pour accomplir des tâches. Ce principe est présenté dans plusieurs cadres de développement, y compris l'ancien Smart Client Software Factory et le plus récent Prism (ou Composite Applications for WPF/Silverlight). Dans ces modèles, les modules d'interface utilisateur sont enregistrés avec un conteneur IoC et chargés selon les besoins en fonction de la configuration et des actions de l'utilisateur. Bien que puissants, ces modèles ont également tendance à avoir une courbe d'apprentissage très abrupte.
L'injection de dépendances est une technique (difficile à appeler un modèle, en fait) de supprimer les dépendances internes des implémentations en permettant aux objets dépendants d'être injectés dans la classe/méthode par un appelant externe. Les frameworks IoC utilisent l'injection de dépendances pour fournir des modules utilisateur et d'autres codes dépendants aux routines de framework qui "collent le tout". L'injection de dépendances est largement utilisée par les frameworks IoC car c'est le mécanisme qui leur permet de "vous appeler".
Les conteneurs IoC, tels que Castle Windsor et Structure Map, aident à l'injection de dépendances en fournissant l'instanciation automatique et la gestion du cycle de vie des classes que vous enregistrez, y compris l'instanciation automatique et l'injection des paramètres requis par les classes enregistrées. Tout cela facilite l'utilisation de l'injection de dépendance, mais n'est pas obligatoire.
L'injection de dépendance est un mécanisme de flexibilité qui maximise la dépendance sur les interfaces tout en minimisant la dépendance sur une implémentation spécifique. Par conséquent, les systèmes qui utilisent l'injection de dépendances peuvent prendre en charge des classes d'implémentation "enfichables" qui peuvent être utilisées en fonction des circonstances. Un très gros avantage de cette "connectabilité" est qu'elle facilite la création de tests unitaires. Vous pouvez vous moquer d'un objet sur l'interface requise, puis l'injecter dans votre objet de test.
Ainsi, l'IoC est vraiment le principe plus large et DI est une technique fondamentale à l'intérieur. Les systèmes IoC (Hollywood Principle) ont tendance à être assez complexes, peuvent être difficiles à comprendre et ont donc des courbes d'apprentissage abruptes. DI, d'autre part est une bonne pratique pour les développeurs de tous les jours. J'ai tendance à préférer compréhensible et clair à cool, mais complexe.
L'IoC est la possibilité de varier la mise en œuvre d'un contrat.
DI est la capacité de fournir l'implémentation.