J'ai lu sur le printemps et que cela a été prétendu être une alternative moins complexe à l'EJB, j'ai du mal à m'envelopper la tête. Existe-t-il un moyen plus minimal d'atteindre une injection de dépendance que d'adopter l'approche de printemps?
9 Réponses :
Pourquoi pas simplement le faire sans cadre?
Demandez ce que votre classe dépend, puis injecte ces objets via (disons) le constructeur.
Quelques astuces:
E.g. Créez simplement une classe avec un constructeur ainsi: (où les deux paramètres sont des interfaces) et vous pouvez alors injecter les composants de base que votre Tradesaver dépend sur (validation et sauvegarde de la base de données), avec la possibilité de fournir différentes implémentations pour les tests, différents déploiements, etc.
"Avec la possibilité de fournir des implémentations différentes pour les tests, des déploiements différents, etc." -> qu'entendez-vous par là?
Vous pouvez fournir une version moquée pour les tests. Pour le déploiement, vous souhaiterez peut-être fournir différentes implémentations d'iTradedatabase pour différents DBS, etc.
Le problème est que ce genre de chose devient très méchante très vite, car vous passez des trucs dans la pile d'appels comme des fous et des méthodes plus élevées au besoin des dizaines de paramètres d'une manière ou d'une autre. Au moment où vous avez encapsulé tout cela, vous avez écrit votre propre trafic (probablement inefficace, probablement mal conçu).
Il est toujours intéressant de faire pour un but d'apprentissage. Par exemple, j'ai honte d'admettre que lorsque le di Craze a commencé à frapper le monde de Java, il y a de nombreuses années, je ne pouvais pas comprendre pourquoi c'était utile (il y avait beaucoup moins d'informations qu'aujourd'hui) ... Alors j'ai écrit mon propre di-cadre et une fois que je l'ai eu, j'ai jeté ma roue (mal conçue).
@Michael - Je suggère simplement d'écrire des constructeurs et d'injection vous-même, plutôt que d'utiliser un cadre. Je ne vois pas comment un cadre atténue le scénario que vous avez décrit.
@Brian: DI Frameworks fournit généralement une usine statique centrale qui fournit des instances avec toutes les dépendances injectées de manière appropriée. Cela supprime le besoin du code d'appel de les transmettre en tant que paramètres de constructeur et répond donc à la question où que code les obtient.
@Michael: Je pense que vous mal comprendre di. La construction d'objets et le graphique d'appel d'objet sont complètement découplés dans DI. L'appelant n'a jamais à s'inquiéter des dépendances de la callee. Un conteneur DI remplace simplement une bande de code de câblage à votre point d'entrée d'application.
@Michael: Si vous passez beaucoup d'arguments haut / bas de la pile, vous le faites mal.
@WIM: C'est pour le cas simple où votre code vit entièrement dans un conteneur et toutes les dépendances sont câblées au démarrage. Si vous n'écrivez pas à une application basée sur des conteneurs ou si votre code doit créer de nouveaux objets avec des dépendances, vous avez besoin d'une usine. Le printemps présente les différentes implémentations de base pour cela, et des cadres de DI plus légers comme Guice l'utilisent exclusivement.
@kyoryu: mon point exactement. Les suggestions de Brian vous oblige à le faire mal à moins que votre application soit très petite et simple.
Je ne suggère pas que vous devez faire quoi que ce soit de manière dogmatique. Vous choisissez ce qui est approprié. Si vous voulez aller plus loin et que vous mettez en œuvre des usines, continuez. À ce stade, vous n'êtes probablement pas injecté, cependant. Le pragmatisme (comme je prêche toujours) est la clé.
Et je ne dis pas que votre réponse est fausse (il décrit la forme la plus élémentaire de DI), juste que son applicabilité est très limitée.
@Michael: Je suis en désaccord avec vous, en fait. Le moyen typique d'éviter d'appeler la pile est d'utiliser des usines plutôt que de l'opérateur "nouveau". Si votre flux logique traite des dépendances, il y a un problème.
@kyoryu: Ah, je pense maintenant que je vois où nous nous méprenons mal. Vous supposez que les arguments du constructeur du code de Brian sont injectés par une usine plutôt que par le code qui les utilise. Mais ensuite, l'usine devient une partie importante du concept, elle doit donc être mentionnée (ce que ce n'est pas). Et vous êtes également à mi-chemin vers l'écriture de votre propre DI Cadre.
@Michael: Oui, mais uniquement pour les cas où les classes doivent être créées de manière dynamique au moment de l'exécution. Dans de nombreux cas, des parties du graphique d'objet sont relativement statiques, ce qui peut être un objet agrégé ou construit par un seul constructeur.
Pourquoi écrivez-vous ce que d'autres ont déjà fait? Il y a probablement beaucoup de petits diables dans les détails.
Une autre option qui n'a pas encore été mentionnée est yan . Je l'ai utilisé dans le passé et c'était très léger et minimaliste. Voici un lien avec une introduction d'une page quant à quoi (et comment) il fait:
En ce qui concerne DI et IOC, cela ne reçoit probablement pas plus minimal que picocontainer .
Je préfère Tapestry , mais Google Guice est assez similaire et plus largement adopté, ce qui pourrait être un meilleur choix car il sera plus facile de trouver Tutoriels, etc.
Je vous recommande vivement d'essayer le printemps. Il est un peu plus compliqué que la Guice dans les étapes initiales, cependant, les wrappers d'autres API et les utilitaires inclus (Ldaptemplate, JDBCTemplate, hibernatetemplate, validateurs, etc.) valent bien le coût de l'admission.
Après avoir dit que, si vous êtes mort-ensemble contre Essayer Spring, Guice ou Seam offre de belles alternatives.
Essentiellement, l'injection de dépendance n'est qu'un moyen de structurer votre code de réutilisabilité des composants. Il ne nécessite pas l'utilisation d'un conteneur. Cela signifie simplement que vous utilisez n'importe quelle utilisation du "nouveau" opérateur pour vos composants au début de votre application. Par exemple, votre point d'entrée d'application pourrait ressembler à ceci:
Container container = new Container(someconfigurationparameters); ZooProgram program = (ZooProgram) container.Create(ZooProgram.class); program.run();
picocontainer est le moyen le plus simple de commencer avec DI:
supposons que nous obtenions puis
Je vous recommanderais vivement de rechercher une implémentation JSR-330, car elles devraient espérons être la norme future. Il y en a un à JeE6 mais cela peut être trop exagéré pour vous. Je croit le Caucho Candi peut courir de manière autonome aussi.