Inversion de contrôle : Avez-vous déjà eu à décider quel cadre d'injection de dépendances est le meilleur pour un projet ? Lequel avez-vous choisi et pourquoi ?

Question

Plutôt que de déclencher une guerre de flammes sur le "meilleur" framework DI (je ne pense pas qu'il y ait une solution générale définitive), cette question a pour but de discuter des bonnes alternatives pour des projets de différents types, quel que soit le langage de programmation, sur la base de l'expérience professionnelle.

J'aimerais me pencher sur certaines questions :

• Quelles étaient les caractéristiques les plus importantes que vous recherchiez dans un cadre de DI ? Pourquoi ce cadre correspondait-il le mieux à votre projet ?
• Qu'est-ce que le cadre DI a de plus que les autres ? Qu'est-ce qui le rend spécial ?
• Pourquoi ne pas choisir le même cadre DI pour d'autres projets ?
• Comment le cadre DI a-t-il amélioré la testabilité et la flexibilité de configuration de l'application (en particulier sur différents environnements : développement, staging, production, etc.)
• De nombreux cadres de DI sont réputés simples. Mais est-il facile de maintenir la configuration des dépendances ? (Par exemple : est-ce trop verbeux ou difficile à lire et à modifier ?)

Je finirai peut-être par accepter une réponse, mais il n'y a pas de "meilleure réponse" à ce sujet. J'apprécierais que toute personne ayant une expérience utile la partage.

Je suis particulièrement intéressé par l'expérience des frameworks DI en Python et PHP, où je pense que le choix n'est pas très simple. La question est cependant indépendante de la langue.

Answer 1

Je choisis généralement les cadres, qu'ils soient DI ou non, en fonction des critères suivants :

1. Choisir un cadre de travail qui possède les fonctionnalités requises pour le travail à effectuer
2. Préférer les cadres simples - Moins il y a de choses "supplémentaires" qui ne sont pas nécessaires pour le point 1, mieux c'est.
3. Préférez les cadres "intégrés" au langage/cadre que vous utilisez déjà.
4. Préférer les cadres que je connais déjà et que j'ai déjà utilisés

En règle générale, il suffit de suivre la procédure décrite ci-dessus pour s'en rendre compte. Par exemple, le dernier cadre DI que j'ai choisi était MEF, principalement parce qu'il s'agissait d'un projet C# (point 3), qu'il était simple et qu'il faisait ce dont j'avais besoin.

Answer 2

En ce qui concerne Java, cela semble assez facile... Il y a Spring avec son DI, et si vous développez en utilisant Printemps il suffit d'utiliser son DI :) Si vous utilisez une autre pile technologique, alors Spring n'est pas si facile à intégrer, et en fait en avez-vous besoin ? Il y a Google Guice :) Par rapport à Spring, Guice est axé sur le DI et dans ce cas, vous n'aurez pas besoin d'ajouter des bibliothèques supplémentaires à votre chemin de classe, peut-être une configuration supplémentaire, etc. De plus, Spring et Guice implémentent tous deux le même JSR 330 (Injection de dépendance pour Java)... Je pense qu'il est assez facile de décider ce qu'il faut utiliser, Spring ou Guice.

D'autre part, Java EE 6 arrive avec sa nouvelle version de JSR 299 (Contextes et injection de dépendances pour le système Java ; CDI ), qui est basé sur la JSR 330. Lorsque vous allez utiliser un serveur d'application compatible avec Java EE 6, il vaut la peine de jeter un coup d'œil à CDI, car vous n'aurez pas besoin de bibliothèques supplémentaires parce que le serveur d'application comprend déjà DI et s'en occupe. CDI vous permet d'aller plus loin car il est superposé à JSR 330 et l'améliore.

Si vous n'utilisez toujours pas Spring/Guice, il est bon de commencer par CDI.

UPDATE : J'ai oublié de mentionner : CDI est maintenant implémenté par le projet Weld (seamframework.org/Weld), il supporte les serveurs les plus courants, vous pouvez donc l'essayer dès maintenant. JBoss AS 6 est livré avec.

Quelques comparaisons entre Spring et Guice, ainsi que des conseils sur le choix de l'un ou l'autre : aquí y aquí