Les cadres d'injection de dépendance posent-ils un risque de dépendance?

J'ai refactorisé un système existant pour utiliser l'injection de dépendances, et ce travail s'est bien déroulé.

Après un certain temps, j'ai remarqué qu'un grand nombre de bibliothèques internes sont devenues dépendantes du framework DI que j'ai utilisé. En conséquence, l'ensemble du projet dépend désormais de ce cadre tiers.

J'ai vu une ironie dans le découplage de toutes les dépendances en les rendant dépendantes d'une bibliothèque partagée.

Ma première réaction a été de créer une bibliothèque d'encapsuleurs autour du framework de dépendance. Par conséquent, je pourrais remplacer ce cadre si nécessaire. Après avoir estimé le travail impliqué, j'ai réalisé que l'API résultante serait similaire au cadre existant, et rendrait donc son remplacement plus difficile. J'ai donc abandonné l'idée.

Ma préoccupation est que le cadre DI que j'utilise devient obsolète ou doit être remplacé.

Existe-t-il un modèle de développement lorsque vous travaillez avec DI qui réduit le couplage entre un projet et le cadre DI?

frameworks dependency-injection

— Reactgular
source

Le modèle "ne pas utiliser de framework DI". Bien que je doive me demander si vous résolvez un problème que vous n'avez pas vraiment - quelle est la probabilité de changer le cadre DI?

— Oded

@Oded un bon framework DI devrait être capable de travailler avec du code de manière transparente, mais il y a des cas où ce n'est pas possible. Vous devez ensuite utiliser les API DI dans vos classes. Dans ces cas, il est difficile de partager ou de modifier le cadre DI sans avoir besoin de changer ces classes. Puisque c'est la première fois que je travaille avec ce cadre DI. Je ne sais pas si je devrai le remplacer.

— Reactgular

Votre système dépend également de l'électricité. Je vous suggère de découpler cela en premier.

— Idan Arye

@MathewFoscarini N'est-ce pas un anti-modèle? Vous pouvez le faire, mais vous ne devriez pas, car cela obscurcit la dépendance.

— maaartinus

@MathewFoscarini DIFramework.Get<IService>()n'est pas réellement une injection de dépendance; c'est un modèle connexe appelé Service Locator. Beaucoup de gens n'aiment pas Service Locator parce qu'il vous couple au framework et parce qu'il est trop facilement abusé (comme Singleton). Martin Fowler a un excellent article sur ces modèles: martinfowler.com/articles/injection.html

— Benjamin Hodgson

Réponses:

Vous avez parfaitement raison - l'utilisation d'un framework DI rendra très probablement votre code dépendant de cette chose. En fait, cela est trop surprenant, car cela est généralement vrai pour toutes les autres bibliothèques de framework ou de fondation, en particulier lorsque cette bibliothèque prend en charge votre projet avec des fonctionnalités génériques utilisées n'importe où dans votre code. Par exemple, lorsque vous décidez d'utiliser un certain cadre d'interface utilisateur ou un cadre Web, cette décision est difficile à modifier par la suite dès que vous avez créé une certaine quantité de code basé sur cette bibliothèque. Lorsque vous décidez d'utiliser une Stringclasse spécifique (peut-être non standard) , vous ne pouvez pas facilement changer cette décision plus tard. Une telle décision est architecturale, c'est comme choisir un certain langage de programmation et essayer de changer cette décision après avoir écrit> 100K lignes de code.

Faire en sorte que tout votre code dépende d'une certaine infrastructure peut ne pas être un problème tant qu'il fait ce que vous attendez de lui et tant qu'il est correctement entretenu. Mais cela peut devenir un problème si ce n'est pas le cas. Il existe certaines stratégies pour faire face à cette situation:

choisissez un framework auprès d'un fournisseur en qui vous avez confiance et qui peut vous fournir des mises à jour et des nouvelles versions dans plusieurs années
choisissez un framework open source qui a suffisamment de lignes de code (et une licence appropriée), afin que vous puissiez faire vous-même toute maintenance, étant donné que le fournisseur disparaît du marché
écrivez votre propre cadre
vivre avec la situation tant que le fournisseur est disponible, et quand il disparaît vraiment, choisissez un cadre différent et essayez de créer un adaptateur qui émule l'ancien cadre en utilisant le nouveau

L'idée de créer une bibliothèque de wrapper à l'avance n'est pas nouvelle du tout, mais j'ai rarement vu cela fonctionner, car vous auriez à faire des hypothèses pour une situation future pour laquelle vous ne savez pas si ou quand cela vous frappera, et quoi le "nouveau" cadre ressemblera. D'un autre côté, il y a quelques années, nous avons réussi à échanger une infrastructure d'interface utilisateur complète dans un projet C ++ avec environ 120 Ko de lignes de code en appliquant la stratégie d'adaptateur mentionnée ci-dessus.

— Doc Brown
source

L'injection de constructeur ordinaire ne nécessite aucun cadre. La seule chose que vous perdez est la possibilité de centraliser vos dépendances dans un fichier de configuration.

Les conteneurs DI sont un modèle de "logiciel d'entreprise", utilisé lorsque le graphe d'objet est très grand et complexe. Je soupçonne que 95% des demandes ne l'exigent pas.

— Robert Harvey
source

Je suis d'accord que les petits projets ne l' exigent pas, mais 95 +% des projets peuvent en profiter .

— maaartinus

@maaartinus: complexité supplémentaire inutile pour un bénéfice minimal.

— Robert Harvey

Qu'est-ce que? Voici mes statistiques par classe: 0,5 annotation, 0,1 ligne de configuration. Alors, quelle complexité voulez-vous dire ???

— maaartinus

@RobertHarvey: bien que je sois d'accord à 100% avec vos déclarations ci-dessus, l'OP indique qu'il a déjà introduit un cadre DI. Lui dire "mieux vaut ne pas" n'est pas vraiment une réponse à sa question.

— Doc Brown

@maaartinus plus le framework s'automatise et plus il peut injecter de choses plus il est complexe. Il existe des fichiers de configuration XML, l'injection de constructeur, l'injection de propriété, le mocking d'objet automatique, l'injection paresseuse, etc. etc. ces cadres DI peuvent devenir très complexes.

— Reactgular

Je ne pense pas que les frameworks DI puissent devenir obsolètes de si tôt. Que doit-il arriver pour le rendre obsolète?

Une invention d'un nouveau modèle plus intelligent peut-être? Quoi qu'il en soit, cela nécessiterait des changements beaucoup plus importants dans le code.
Un changement de langue peut-être? Encore pire.

Je dirais que la DI actuelle est suffisamment mûre et je ne suis pas au courant de grand-chose. Vous n'avez pas spécifié votre langue, donc en parlant de Guice , il est assez non intrusif et fonctionne avec des annotations Java standard (utilise également le leur pour des choses non normalisées, mais vous en avez rarement besoin). Il est open source, largement utilisé et sous licence Apache. Quel pourrait être le problème?

Je suis à peu près sûr que changer le cadre DI serait plus facile que de changer toute autre bibliothèque (par exemple, un changement d'interface signifie beaucoup plus de travail).

— maaartinus
source