Injection de dépendance: dois-je utiliser un framework?

24

J'ai récemment travaillé sur un projet Python où nous avons fait beaucoup d'injection de dépendances (parce que nous devons pour que l'application soit testable), mais nous n'avons utilisé aucun framework. Parfois, c'était un peu fastidieux de câbler toutes les dépendances manuellement, mais dans l'ensemble, cela fonctionnait très bien.

Lorsqu'un objet devait être créé à plusieurs endroits, nous avions simplement une fonction (parfois une méthode de classe de cet objet) pour créer une instance de production. Cette fonction était appelée chaque fois que nous avions besoin de cet objet.

Dans les tests, nous avons fait la même chose: si plusieurs fois nous devions créer une «version de test» d'un objet (c'est-à-dire une instance réelle soutenue par des objets factices), nous avions une fonction pour créer cette «version de test» d'une classe, à utiliser dans les tests.

Comme je l'ai dit, cela fonctionnait généralement bien.

J'entre maintenant dans un nouveau projet Java, et nous décidons d'utiliser un framework DI ou de faire DI manuellement (comme dans le projet précédent).

Veuillez expliquer en quoi le travail avec un framework DI sera différent, et de quelles manières il est meilleur ou pire que l'injection manuelle de dépendance «vanille».

Edit: Je voudrais également ajouter à la question: avez-vous été témoin d'un projet de «niveau professionnel» qui fait de l'ID manuellement, sans cadre?

Aviv Cohn
la source
A côté de ma réponse. Les deux façons sont compatibles. Vous pouvez laisser l'injection de dépendances douces au framework et conserver vos usines pour les composants critiques. Composants liés au modèle ou à l'entreprise.
Laiv
4
Je suppose que vous avez déjà vérifié, juste au cas où vous ne le feriez pas Pourquoi avons-nous besoin de cadres pour DI?
Laiv

Réponses:

19

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.
Laiv
la source
1
«Ces frameworks ne vous sont pas réservés pour effectuer des tests unitaires ou des tests d'intégrité, alors ne vous inquiétez pas des tests.» Qu'est-ce que cela signifie exactement? La formulation me fait penser que c'est une faute de frappe mais j'ai du mal à la décoder.
candied_orange
Cela signifie que le débogage difficile ou l'utilisation des frameworks pour les tests ne sont pas assez d'inconvénients à éliminer pour utiliser ces frameworks. Parce que même si vous ne les aimez pas, ils ont toujours des avantages qui valent vraiment la peine d'être essayés. Les gros inconvénients ne sont pas des cadres par eux-mêmes. C'est comme ça que vous les utilisez. Certaines bonnes pratiques comme les interfaces et les setters sont toujours nécessaires même si votre framework ne le fait pas. Enfin, il existe de bonnes bibliothèques de test qui s'intègrent facilement à ce type de Frameworks (DI)
Laiv
Si c'est ce que vous voulez dire, considérez: "Ces frameworks ne vous empêchent pas d'effectuer des tests unitaires ou des tests d'intégrité, alors ne vous inquiétez pas de leur impact sur les tests"
candied_orange
Srry. J'essaie de dire qu'il pourra tester son code même avec ces frameworks. Malgré l'abstraction, les tests sont toujours réalisables. N'hésitez pas à modifier ma réponse. Comme vous le voyez, mon anglais est encore loin d'être décent :-)
Laiv
1
Notez que Dagger2 fait DI légèrement différent. Le code de collage est généré au moment de la compilation en tant que sources Java normales et lisibles, il est donc beaucoup plus simple de suivre la façon dont les choses sont collées ensemble au lieu d'avoir à gérer la magie d'exécution.
Thorbjørn Ravn Andersen
10

D'après mon expérience, un cadre d'injection de dépendances entraîne un certain nombre de problèmes. Certains problèmes dépendront du cadre et des outils. Il peut y avoir des pratiques qui atténuent les problèmes. Mais ce sont les problèmes que j'ai rencontrés.

Objets non globaux

Dans certains cas, vous souhaitez injecter un objet global: un objet qui n'aura qu'une seule instance dans votre application en cours d'exécution. Cela peut être a MarkdownToHtmlRendererer, a DatabaseConnectionPool, l'adresse de votre serveur api, etc. Pour ces cas, les frameworks d'injection de dépendances fonctionnent très simplement, il vous suffit d'ajouter la dépendance nécessaire à votre constructeur et vous l'avez.

Mais qu'en est-il des objets qui ne sont pas globaux? Et si vous avez besoin de l'utilisateur pour la demande actuelle? Que faire si vous avez besoin de la transaction de base de données actuellement active? Et si vous avez besoin de l'élément HTML correspondant à la div qui contient un formulaire dans lequel se trouve une zone de texte qui vient de déclencher un événement?

La solution que j'ai vue utilisée par les frameworks DI est les injecteurs hiérarchiques. Mais cela rend le modèle d'injection plus compliqué. Il devient plus difficile de comprendre exactement ce qui sera injecté à partir de quelle couche de la hiérarchie. Il devient difficile de dire si un objet donné existera par application, par utilisateur, par demande, etc. Vous ne pouvez plus simplement ajouter vos dépendances et le faire fonctionner.

Bibliothèques

Souvent, vous voudrez avoir une bibliothèque de code réutilisable. Cela comprendra également les instructions sur la façon de construire des objets à partir de ce code. Si vous utilisez un framework d'injection de dépendances, cela inclura généralement des règles de liaison. Si vous souhaitez utiliser la bibliothèque, vous ajoutez leurs règles de liaison aux vôtres.

Cependant, divers problèmes peuvent en résulter. Vous pouvez vous retrouver avec la même classe liée à différentes implémentations. La bibliothèque peut s'attendre à ce que certaines liaisons existent. La bibliothèque peut remplacer certaines liaisons par défaut, ce qui fait que votre code fait une chose étrange. Votre code peut remplacer une liaison par défaut, ce qui fait que le code de la bibliothèque fait des choses étranges.

Complexité cachée

Lorsque vous écrivez manuellement des usines, vous avez une idée de la façon dont les dépendances de l'application s'emboîtent. Lorsque vous utilisez un framework d'injection de dépendances, vous ne voyez pas cela. Au lieu de cela, les objets ont tendance à croître de plus en plus de dépendances jusqu'à ce que tout dépend tôt ou tard de tout.

Prise en charge IDE

Votre IDE ne comprendra probablement pas le cadre d'injection de dépendance. Avec les usines manuelles, vous pouvez trouver tous les appelants d'un constructeur pour comprendre tous les endroits où l'objet pourrait être construit. Mais il ne trouvera pas les appels générés par le framework DI.

Conclusion

Qu'obtenons-nous d'un cadre d'injection de dépendances? Nous arrivons à éviter un passe-partout simple nécessaire pour instancier des objets. Je suis pour l'élimination du passe-partout simple. Cependant, le maintien d'un passe-partout simple d'esprit est facile. Si nous voulons remplacer ce passe-partout, nous devons insister pour le remplacer par quelque chose de plus facile. En raison des diverses questions dont j'ai discuté ci-dessus, je ne pense pas que les cadres (du moins en l'état) correspondent au projet de loi.

Winston Ewert
la source
C'est une très bonne réponse, mais je ne peux pas imaginer utiliser un conteneur IoC pour une bibliothèque de classes. Cela me semble un mauvais design. Je m'attendrais à ce qu'une bibliothèque me donne explicitement toutes les dépendances dont elle a besoin.
RubberDuck
@RubberDuck, dans mon cas, j'ai travaillé pour une grande entreprise avec un grand nombre de projets java tous standardisés sur le même framework d'injection de dépendances. À ce stade, il devient tentant pour certaines équipes d'exporter une bibliothèque qui s'attend à être constituée par le cadre DI, plutôt que de fournir une interface externe sensible.
Winston Ewert
C'est malheureux @WinstonEwert. Merci d'avoir rempli le contexte pour moi.
RubberDuck
Ce serait formidable pour la partie IDE, avec la liaison d'exécution des infrastructures d'injection par opposition à la liaison de type conception des injections manuelles. Le compilateur empêche les injections oubliées lorsqu'elles sont manuelles.
Basilevs
IntelliJ comprend le CDI (Java EE standard DI)
Thorbjørn Ravn Andersen
3

Est-ce que Java + injection de dépendances = framework requis?

Non.

Qu'est-ce qu'un framework DI m'achète?

La construction d'objets se passe dans un langage qui n'est pas Java.


Si les méthodes d'usine sont assez bonnes pour vos besoins, vous pouvez faire DI en java complètement sans framework en 100% pojo java authentique. Si vos besoins vont au-delà, vous avez d'autres options.

Les modèles de conception de Gang of Four accomplissent beaucoup de grandes choses, mais ont toujours eu des faiblesses en ce qui concerne les modèles de création. Java lui-même présente quelques faiblesses. Les cadres DI aident vraiment à cette faiblesse créative plus qu'ils ne le font avec les injections réelles. Vous savez déjà comment faire cela sans eux. Le bien qu'ils vous feront dépendra de l'aide dont vous avez besoin pour la construction d'objets.

Il existe de nombreux modèles de création qui sont apparus après le Gang of Four. Le générateur Josh Bloch est un merveilleux hack autour du manque de paramètres nommés de Java. Au-delà de cela, les constructeurs iDSL offrent beaucoup de flexibilité. Mais chacun d'entre eux représente un travail et un passe-partout importants.

Les cadres peuvent vous sauver d'une partie de cet ennui. Ils ne sont pas sans inconvénients. Si vous ne faites pas attention, vous pouvez vous retrouver dépendant du framework. Essayez de changer de framework après en avoir utilisé un et voyez par vous-même. Même si vous conservez en quelque sorte le xml ou les annotations génériques, vous pouvez finir par prendre en charge ce qui sont essentiellement deux langues que vous devez mentionner côte à côte lorsque vous publiez des travaux de programmation.

Avant de devenir trop amoureux de la puissance des frameworks DI, prenez un peu de temps et étudiez d'autres frameworks qui vous offrent des capacités que vous pourriez autrement penser avoir besoin d'un framework DI. Beaucoup se sont diversifiés au-delà de la simple DI . Considérez: Lombok , AspectJ et slf4J . Chacun chevauche certains cadres DI, mais chacun fonctionne très bien seul.

Si le test est vraiment la force motrice derrière cela, veuillez regarder: jUnit (n'importe quelle xUnit vraiment) et Mockito (n'importe quelle maquette vraiment) avant de commencer à penser qu'un cadre DI devrait prendre le dessus sur votre vie.

Vous pouvez faire ce que vous voulez, mais pour un travail sérieux, je préfère une boîte à outils bien remplie à un couteau suisse. J'aimerais qu'il soit plus facile de dessiner ces lignes, mais certains ont travaillé dur pour les brouiller. Rien de mal à cela, mais cela peut rendre ces choix difficiles.

CandiedOrange
la source
PowerMock a résolu certains de ces cas. Au moins, il vous a permis de simuler la statique
Laiv
Meh. Si vous faites DI correctement, il devrait être relativement simple de remplacer un framework IoC Container par un autre. Gardez ces annotations hors de votre code et tout ira bien. Fondamentalement, utilisez le conteneur IoC pour effectuer DI au lieu d'utiliser le conteneur comme localisateur de services.
RubberDuck
@RubberDuck correct. À moins de tester et de maintenir constamment votre base de code sous plusieurs cadres DI, connaissez-vous un moyen simple et fiable de vérifier que "vous faites DI correctement"? Même si je n'utilise que des pojo en java, si des efforts importants ont été faits pour créer le XML, ce n'est toujours pas un simple échange lorsque le XML dépend du conteneur IoC.
candied_orange
@CandiedOrange J'utilise "simple" comme terme relatif. Dans le grand schéma des choses, remplacer une racine de composition par une autre n'est pas une tâche trop difficile. Quelques jours de travail. Quant à vous assurer que vous faites DI correctement, c'est à cela que servent les revues de code.
RubberDuck
2
@RubberDuck la plupart des "racines de composition" que j'ai vues sont environ 5 lignes de code en général. Donc non. pas une tâche trop difficile. C'est le truc propriétaire qui échappe à ces lignes contre lesquelles je mets en garde. Vous l'appelez "faire DI correctement". Je vous demande ce que vous utiliseriez pour prouver un problème dans une revue de code. Ou diriez-vous simplement "Meh"?
candied_orange
2

La création de classes et leur affectation de dépendances fait partie du processus de modélisation, les parties amusantes. C'est la raison pour laquelle la plupart des programmeurs aiment la programmation.

Décider quelle implémentation sera utilisée et comment les classes sont construites est une chose qui devra être implémentée d'une manière ou d'une autre et fera partie de la configuration de l'application.

L'écriture manuelle des usines est un travail fastidieux. Les infrastructures DI facilitent la tâche en résolvant automatiquement les dépendances qui peuvent être résolues et en exigeant une configuration pour celles qui ne le sont pas.

L'utilisation d'IDE modernes vous permet de parcourir les méthodes et leurs utilisations. Avoir des usines écrites manuellement est assez bon, car vous pouvez simplement mettre en évidence le constructeur d'une classe, montrer ses usages, et cela vous montrera tous les endroits où et comment la classe spécifique est en cours de construction.

Mais même avec le framework DI, vous pouvez avoir une place centrale, comme la configuration de construction de graphe d'objet (OGCC à partir de maintenant), et si une classe dépend de dépendances ambiguës, vous pouvez simplement regarder OGCC et voir comment une classe spécifique est en cours de construction juste là.

Vous pourriez objecter que vous pensez personnellement pouvoir voir les usages d'un constructeur spécifique est un grand plus. Je dirais que ce qui ressort mieux pour vous n'est pas seulement subjectif, mais vient surtout de l'expérience personnelle.

Si vous aviez toujours travaillé sur des projets qui s'appuyaient sur des frameworks DI, vous ne le sauriez vraiment que lorsque vous vouliez voir une configuration d'une classe, vous regarderiez toujours OGCC et n'essaieriez même pas de voir comment les constructeurs sont utilisés , car vous savez que les dépendances sont toutes câblées automatiquement de toute façon.

Naturellement, les frameworks DI ne peuvent pas être utilisés pour tout et de temps en temps, vous devrez écrire une ou deux méthodes d'usine. Un cas très courant est la construction d'une dépendance pendant l'itération sur une collection, où chaque itération fournit un indicateur différent qui devrait produire une implémentation différente d'une interface par ailleurs commune.

En fin de compte, tout dépendra très probablement de vos préférences et de ce que vous êtes prêt à sacrifier (soit en écrivant du temps dans les usines, soit en transparence).


Expérience personnelle (avertissement: subjectif)

Parlant en tant que développeur PHP, bien que j'aime l'idée derrière les frameworks DI, je ne les ai utilisés qu'une seule fois. C'est à ce moment-là qu'une équipe avec laquelle je travaillais était censée déployer une application très rapidement et nous ne pouvions pas perdre de temps à écrire des usines. Nous avons donc simplement choisi un framework DI, l'avons configuré et cela a fonctionné d'une manière ou d'une autre .

Pour la plupart des projets, j'aime que les usines soient écrites manuellement parce que je n'aime pas la magie noire qui se passe dans les frameworks DI. J'étais le responsable de la modélisation d'une classe et de ses dépendances. C'est moi qui décidais pourquoi le design ressemblait à ça. Je serai donc celui qui construit correctement la classe (même si la classe prend des dépendances dures, telles que des classes concrètes au lieu d'interfaces).

Andy
la source
2

Personnellement, je n'utilise pas de conteneurs DI et je ne les aime pas. J'ai quelques autres raisons à cela.

Il s'agit généralement d'une dépendance statique. Il ne s'agit donc que d'un localisateur de services avec tous ses inconvénients. Ensuite, en raison de la nature des dépendances statiques, elles sont masquées. Vous n'avez pas besoin de vous en occuper, ils sont déjà en quelque sorte là, et c'est dangereux, car vous cessez de les contrôler.

Il rompt les principes de la POO , tels que la cohésion et la métaphore de l'objet Lego-brick de David West .

Donc, la construction de l'objet entier aussi près que possible du point d'entrée du programme est la voie à suivre.


la source
1

Comme vous l'avez déjà remarqué: selon la langue que vous utilisez, il existe différents points de vue, différentes manières de gérer des problèmes similaires.

En ce qui concerne l'injection de dépendances, cela se résume à ceci: l'injection de dépendances n'est, comme le terme le dit, rien de plus que de mettre les dépendances dont un objet a besoin dans cet objet - contrairement à l'autre: laisser l'objet lui-même instancier des instances d'objets dont il dépend. Vous dissociez la création et la consommation d'objets pour gagner en flexibilité.

Si votre conception est bien structurée, vous avez généralement peu de classes avec de nombreuses dépendances, donc le câblage des dépendances - à la main ou par un framework - devrait être relativement facile et la quantité de passe-partout pour écrire les tests devrait être facile à gérer.

Cela dit, il n'y a pas besoin d'un cadre DI.

Mais pourquoi voulez-vous quand même utiliser un framework?

I) Évitez le code passe-partout

Si votre projet prend de la taille, où vous ressentez la douleur d'écrire des usines (et des instatiations) encore et encore, vous devez utiliser un cadre DI

II) Approche déclinative de la programmation

Lorsque Java programmait autrefois avec XML, c'est maintenant: saupoudrer Fairydust d'annotations et la magie opère .

Mais sérieusement: je vois un net avantage à cela. Vous communiquez clairement votre intention en disant ce qui est nécessaire plutôt que où le trouver et comment le construire.


tl; dr

Les frameworks DI n'améliorent pas votre base de code comme par magie, mais cela aide à rendre le code beau vraiment net . Utilisez-le lorsque vous en ressentez le besoin. À un certain moment de votre projet, cela vous fera gagner du temps et évitera les nausées.

Thomas Junk
la source
1
Vous avez raison! J'ai tendance à trop m'inquiéter de la façon dont les choses fonctionnent sous le capot. J'ai eu des expériences horribles en travaillant avec des frameworks que je comprenais à peine. Je ne préconise pas de tester les frameworks, juste comprendre ce qu'ils font et comment ils le font (si possible). Mais cela dépend de vos propres intérêts. Je pense qu'en comprenant comment ils fonctionnent, vous êtes mieux placé pour décider s'ils vous conviennent. Par exemple, de la même manière que vous compareriez différents ORM.
Laiv
1
Je pense qu'il est toujours juste de savoir comment les choses fonctionnent sous le capot. Mais cela ne devrait pas vous faire peur de ne pas savoir. Je pense que le point de vente pour le printemps , par exemple est, qu'il vient fonctionne. Et oui, vous avez tout à fait raison, afin de prendre une décision éclairée quant à l'utilisation d'un cadre, vous devez avoir un certain degré de connaissance. Mais je vois trop souvent un schéma de méfiance pour les gens qui n'ont pas les mêmes cicatrices que soi, mais pas dans votre cas, où l'on croit, seul celui qui a fait l'expérience de la chasse manuelle est autorisé à aller au supermarché.
Thomas Junk
Heureusement, ces jours-ci, nous n'avons même pas besoin de frameworks Spring ou DI pour Java. Nous avons déjà le JSR330 qui est malheureusement ignoré (au moins, je n'ai pas vu de projet l'implémenter). Donc, les gens ont encore le temps de gagner leurs cicatrices :-)
Laiv
J'ai édité ma réponse et j'ai pris en considération vos commentaires. J'ai supprimé les "inconvénients" liés au débogage. J'en suis venu à la conclusion que vous aviez raison là-dessus. Jetez un coup d'œil et envisagez de mettre à jour votre réponse également, car en ce moment, vous citez des parties que j'ai supprimées de ma réponse.
Laiv
1
La réponse a si peu changé !!! Rien qui ne devrait vous inquiéter :-). Le message et les arguments restent les mêmes. Je voulais juste que votre réponse reste telle qu'elle est. Je suppose qu'il vous a juste fallu supprimer l'une des citations.
Laiv
0

Oui. Vous devriez probablement lire le livre de Mark Seemann intitulé "Dependency Injection". Il décrit quelques bonnes pratiques. Sur la base de certains de vos propos, vous pourriez en bénéficier. Vous devez viser à avoir une racine de composition ou une racine de composition par unité de travail (par exemple, une demande Web). J'aime sa façon de penser que tout objet que vous créez est considéré comme une dépendance (tout comme n'importe quel paramètre d'une méthode / constructeur), vous devez donc faire très attention où et comment vous créez des objets. Un cadre vous aidera à garder ces concepts clairs. Si vous lisez le livre de Mark, vous trouverez plus que la réponse à votre question.

Keith
la source
0

Oui, lorsque je travaille en Java, je recommanderais un framework DI. Il y a plusieurs raisons à cela:

  • Java possède plusieurs très bons packages DI qui offrent une injection de dépendances automatisée et sont également généralement fournis avec des capacités supplémentaires plus difficiles à écrire manuellement que les DI simples (par exemple, les dépendances étendues qui permettent une connexion automatique entre les étendues en générant du code pour rechercher dans quelle étendue devrait être utilisez un d pour trouver la version correcte de la dépendance pour cette portée - ainsi, par exemple, les objets de portée d'application peuvent se référer à ceux de portée de demande).

  • les annotations java sont extrêmement utiles et fournissent un excellent moyen de configurer les dépendances

  • la construction des objets java est trop verbeuse par rapport à ce à quoi vous êtes habitué en python; L'utilisation d'un cadre ici permet d'économiser plus de travail que dans un langage dynamique.

  • Les frameworks java DI peuvent faire des choses utiles comme générer automatiquement des mandataires et des décorateurs qui fonctionnent plus en Java qu'un langage dynamique.

Jules
la source
0

Si votre projet est assez petit et que vous n'avez pas beaucoup d'expérience avec le DI-Framework, je recommanderais de ne pas utiliser le framework et de le faire manuellement.

Raison: J'ai déjà travaillé dans un projet qui utilisait deux bibliothèques qui avaient des dépendances directes avec différents cadres di. ils avaient tous deux un code spécifique au framework comme di-give-me-an-instance-of-XYZ. Autant que je sache, vous ne pouvez avoir qu'une seule implémentation active de di-framework à la fois.

avec un code comme celui-ci, vous pouvez faire plus de mal que d'avantages.

Si vous avez plus d'expérience, vous supprimerez probablement le di-framwork par une interface (usine ou servicelocator) de sorte que ce problème n'existera plus et que le cadre di profitera davantage à ce mal.

k3b
la source