Utilité du producteur (@produces)
Bonjour,
Je suis en train de migrer une application java ee qui n'utilise pas CDI pour utiliser cette technologie que je ne connais pas encore très bien.
D'après ce que j'ai lu, un des avantages de CDI est de diminuer fortement le couplage entre les dépendances.
Ok, ça j'ai bien compris. Je fais un @Inject sur une interface et CDI ce charge de créer une instance de la bonne implémentation.
Si un jour je change d'implémentation, j'ai juste une classe à ajouter pour cette dernière, avec un @Default et des @Alternative pour les autres, redéployer et le tour est joué.
J'ai testé et c'est vrai que c'est génial, ça marche super bien.
Par contre j'ai un peu de mal avec le concept de producteur.
Un des exemple fréquent trouvé sur le net est son usage avec un logger. Et c'est d'ailleurs ce qui m'intéresse.
Jusqu'à présent dans l'application il y a dans un bon nombre de classes
Code:
Logger log = LoggerFactory.getLogger(MyClass.class);
avec Logger qui est une classe propre à mon entreprise mais basée sur log4j.
Avec CDI j'aurais
et le producteur (avec @Produces) qui retroune une instance de Logger issu disons du package mywork.logger.
Et c'est là que je ne comprends pas. C'est plus court à écrire, ok, mais le couplage est toujours aussi fort qu'avec la version non-CDI.
Si dans 6 mois je change de logger, je dois modifier le producteur, ça je veux bien, mais je dois aussi modifier toutes les classes qui l'utilisent.
Donc où est l'intérêt ?
