Je suis comme toi j'aime bien utiliser des choses que je comprends :) L'intérêt des moteurs d'injection comme guice, hk2 , jodd, et SilkDi (le petit nouveau) c est justement d'être simple et compréhensible lorsque tu codes une application. tu sais ce que tu fais ça compile, c'est la classe.
Comme toi je n'aime pas l'annotationporn mais si j'utilise des annotations il faut que ce soit les miennes avec des comportements que j'ai décidé.
Je te rejoins tout à fait dans ton raisonnement, le problème que je cherchais à résoudre est celui-ci :
1) Un développeur qui créé souvent des applications avec souvent les mêmes composants à injecter va vouloir les réutiliser simplement sans copier/coller la configuration à chaque fois. Le coté déclaratif plutot qu'impératif fait que tu ne te préoccupes plus de la configuration. Les conventions que tu as décidé (exemple plus haut) seront valable sur tous tes projets, tu commences à coder sans penser à la configuration du moteur d'injection.
2) Dans le cadre d'une entreprise (plutot une corporation) avec > 1000 développeurs avec toutes les problématiques qui vont avec (niveaux des developpeurs hétérogènes, développeurs interne vs externe, SSII aux forfaits, offshore, plusieurs langues etc ) → Il faut prévoir des buildings blocs suffisament autonomes pour que les développeurs se concentrent sur le code métier et non le « code technique » . Avoir un socle technique permet de standardiser sans alourdir et d'avoir moins d'erreur
C'est dans cet esprit que respectivement nuun et seedstack ont été créé. Pour une application classique, nuun est aussi utilisable tu codes juste ton module Guice tu lui colle un @Install dessus et ça roule. Une dernière chose, nuun est compatible guice, spring, hk2, jodd etc etc car il wrap le moteur d'injection. Cela veut dire que tu peux utiliser au sein d'une même appli de la conf spring, guice, hk2 et Jodd (ce sont des exemples que je prépare pour la documentation)
Par contre j'ai une question du coup. Comment fais-tu pour reconfigurer ton injection ? Il est important pour moi de pouvoir :
configurer l'injection à partir de la configuration de mon application
configurer l'injection pour injecter des mocks lors de mes tests
Pour reconfigurer l'application est ce que tu peux me donner un exemple précis ? Mais comme ton plugin est du code java tu peux rajouter les regles de reconfiguration que tu veux ou alors utiliser un autre plugin ton application fonctionnera juste différement. Autre chose, Nuun supporte les qualifiers de la JSR330 ce qui veut dire que pour tu peux qualifier ton injection dans notre exemple plus haut.
@Inject @Name("colissimo") //@Colissimo est aussi possible
ShippingBusinessRule colissimoShipping; // ColissimoShipping sera injecté
Pour les mocks, c est simple tu peux déclarer des bindings d'override (au cas par cas) qui vont faire qu'en cas de test tu utiliseras ton Mock à la place de la vraie implémentation, c est un cas que j'ai pris en compte dès le départ étant moi même friand de Mock.
[^] # Re: GO GO GO GO
Posté par Narmer . En réponse au journal The Go Programming Language. Évalué à 0.
Je suis comme toi j'aime bien utiliser des choses que je comprends :) L'intérêt des moteurs d'injection comme guice, hk2 , jodd, et SilkDi (le petit nouveau) c est justement d'être simple et compréhensible lorsque tu codes une application. tu sais ce que tu fais ça compile, c'est la classe.
Comme toi je n'aime pas l'annotationporn mais si j'utilise des annotations il faut que ce soit les miennes avec des comportements que j'ai décidé.
Je te rejoins tout à fait dans ton raisonnement, le problème que je cherchais à résoudre est celui-ci :
1) Un développeur qui créé souvent des applications avec souvent les mêmes composants à injecter va vouloir les réutiliser simplement sans copier/coller la configuration à chaque fois. Le coté déclaratif plutot qu'impératif fait que tu ne te préoccupes plus de la configuration. Les conventions que tu as décidé (exemple plus haut) seront valable sur tous tes projets, tu commences à coder sans penser à la configuration du moteur d'injection.
2) Dans le cadre d'une entreprise (plutot une corporation) avec > 1000 développeurs avec toutes les problématiques qui vont avec (niveaux des developpeurs hétérogènes, développeurs interne vs externe, SSII aux forfaits, offshore, plusieurs langues etc ) → Il faut prévoir des buildings blocs suffisament autonomes pour que les développeurs se concentrent sur le code métier et non le « code technique » . Avoir un socle technique permet de standardiser sans alourdir et d'avoir moins d'erreur
C'est dans cet esprit que respectivement nuun et seedstack ont été créé. Pour une application classique, nuun est aussi utilisable tu codes juste ton module Guice tu lui colle un @Install dessus et ça roule. Une dernière chose, nuun est compatible guice, spring, hk2, jodd etc etc car il wrap le moteur d'injection. Cela veut dire que tu peux utiliser au sein d'une même appli de la conf spring, guice, hk2 et Jodd (ce sont des exemples que je prépare pour la documentation)
Pour reconfigurer l'application est ce que tu peux me donner un exemple précis ? Mais comme ton plugin est du code java tu peux rajouter les regles de reconfiguration que tu veux ou alors utiliser un autre plugin ton application fonctionnera juste différement. Autre chose, Nuun supporte les qualifiers de la JSR330 ce qui veut dire que pour tu peux qualifier ton injection dans notre exemple plus haut.
Pour les mocks, c est simple tu peux déclarer des bindings d'override (au cas par cas) qui vont faire qu'en cas de test tu utiliseras ton Mock à la place de la vraie implémentation, c est un cas que j'ai pris en compte dès le départ étant moi même friand de Mock.