La clé des conteneurs DI est l'abstraction . Les conteneurs DI résument cette préoccupation de conception pour vous. Comme vous pouvez le deviner, cela a un impact notable sur le code, souvent traduit par un nombre moins important de constructeurs, de setters, d'usines et de builders. En conséquence, ils rendent votre code plus faiblement couplé (en raison de l' IoC sous-jacent ), plus propre et plus simple. Mais pas sans frais.
Arrière-plans
Il y a des années, une telle abstraction nous obligeait à écrire différents fichiers de configuration ( programmation déclarative ). C'était fantastique de voir le nombre de LOC diminuer considérablement, mais alors que les LOCS diminuaient, le nombre de fichiers de configuration augmentait légèrement. Pour les projets de moyenne ou petite envergure, ce n'était pas du tout un problème, mais pour les grands projets, avoir "l'assemblage du code" dispersé à 50% entre le code et les descripteurs XML est devenu une douleur dans le ... Néanmoins, le principal problème était le le paradigme lui-même. C'était assez rigide parce que les descripteurs laissaient peu d'espace pour les personnalisations.
Le paradigme s'est progressivement déplacé vers la convention sur la configuration , qui échange les fichiers de configuration contre des annotations ou des attributs. Il maintient notre code plus propre et plus simple tout en nous offrant la flexibilité que XML ne pouvait pas.
Il s'agit probablement de la différence la plus importante concernant la façon dont vous travailliez jusqu'à présent. Moins de code et plus de magie.
Sur le plan négatif ...
La convention sur la configuration rend l'abstraction si lourde que vous savez à peine comment elle fonctionne. Cela semble parfois magique et voici encore un inconvénient. Une fois que cela fonctionne, de nombreux développeurs ne se soucient pas de la façon dont cela fonctionne.
C'est un handicap pour ceux qui ont appris DI avec des conteneurs DI. Ils ne comprennent pas pleinement la pertinence des modèles de conception, les bonnes pratiques et les principes qui ont été abstraits par le conteneur. J'ai demandé aux développeurs s'ils étaient familiarisés avec DI et ses avantages et ils ont répondu: - Oui, j'ai utilisé Spring IoC -. (Qu'est-ce que ça signifie?!?)
On peut être d'accord ou non avec chacun de ces "inconvénients". À mon humble avis, il est indispensable de savoir ce qui se passe dans votre projet. Sinon, nous ne le comprenons pas complètement. Est aussi de savoir à quoi sert DI et d'avoir une idée de la façon de l'implémenter est un plus à considérer.
Du coté positif...
Productivité en un mot . Les cadres nous permettent de nous concentrer sur ce qui compte vraiment. Le métier de l'application.
Malgré les lacunes commentées, pour beaucoup d'entre nous (dont le travail est conditionné par les délais et les coûts), ces outils sont une ressource inestimable. À mon avis, cela devrait être notre principal argument en faveur de la mise en œuvre d'un conteneur DI. Productivité .
Essai
Que ce soit si nous implémentons des DI purs ou des conteneurs, les tests ne seront pas un problème. Plutôt l'inverse. Les mêmes conteneurs nous fournissent souvent les simulations pour les tests unitaires hors de la boîte. Au fil des ans, j'ai utilisé mes tests comme thermomètres. Ils me disent si je me suis beaucoup appuyé sur les installations de conteneurs. Je dis cela parce que ces conteneurs peuvent initialiser des attributs privés sans setters ni constructeurs. Ils peuvent injecter des composants presque partout!
Cela semble tentant non? Faites attention! Ne tombez pas dans le piège !!
Suggestions
Si vous décidez de mettre en œuvre des conteneurs, je vous suggère fortement de respecter les bonnes pratiques. Continuez à implémenter les constructeurs, les setters et les interfaces. Appliquez le framework / conteneur pour les utiliser . Cela facilitera les migrations possibles vers un autre framework ou supprimera le framework actuel. Cela peut réduire considérablement la dépendance à l'égard du conteneur.
Concernant ces pratiques:
Quand utiliser les conteneurs DI
Ma réponse va être biaisée par sa propre expérience qui est principalement en faveur des conteneurs DI (comme je l'ai dit, je suis fortement concentré sur la productivité, donc je n'ai jamais eu besoin d'une DI pure. Bien au contraire).
Je pense que vous trouverez un article intéressant de Mark Seeman sur ce sujet, qui répond également à la question de savoir comment implémenter la DI pure .
Enfin, si nous parlions de Java, j'envisagerais d' abord de jeter un œil au JSR330 - Dependency Injection .
Résumer
Bénéfices :
- Réduction des coûts et gain de temps. Productivité.
- Un plus petit nombre de composants.
- Le code devient plus simple et plus propre.
Désavantages :
- DI est délégué à des bibliothèques tierces. Nous devons être conscients de leurs compromis, de leurs forces et de leurs faiblesses.
- Courbe d'apprentissage.
- Ils vous font vite oublier de bonnes habitudes.
- Augmentation des dépendances du projet (plus de libs)
- Les conteneurs basés sur la réflexion nécessitent plus de ressources (mémoire). C'est important si nous sommes limités par les ressources.
Différences avec DI pur :
- Moins de code et plus de fichiers de configuration ou d'annotations.