Google Guice contre JSR-299 CDI / Weld
Weld, l'implémentation de référence JSR-299 Contexts and Dependency Injection, se considère comme une sorte de successeur de Spring and Guice.
CDI a été influencé par un certain nombre de frameworks Java Java, y compris Seam, Guice et Spring. Cependant, CDI a son propre caractère, très distinct: plus sûr pour les types que Seam, plus dynamique et moins XML- centrée sur Spring, plus web et capable d’applications d’entreprise que Guice. Mais cela n’aurait pas pu être sans l’inspiration des frameworks mentionnés et beaucoup de collaboration et de travail acharné par le JSR-299 Expert Group (EG).
http://docs.jboss.org/weld/reference/latest/en-US/html/1.html
Qu'est-ce qui rend Weld plus capable pour les applications d'entreprise que Guice? Y a-t-il des avantages ou des inconvénients par rapport à Guice? Que pensez-vous du Guice AOP par rapport aux intercepteurs Weld? Et la performance?
Mon choix
En fin de compte, j'ai décidé d'utiliser Guice parce que j'aime le modèle de programmation propre qui vient presque sans annotations en plus de @Inject par défaut. Il est beaucoup plus facile d'utiliser des bibliothèques externes avec Guice qu'avec CDI. AOP est également assez simple avec Guice.
Avant d'essayer de répondre à votre question, permettez-moi d'ajouter une information importante: JSR 3 (@Inject) a été normalisé par les projets Guice et Spring ( annonce de mai 2009 ) et est réutilisé dans JSR 299 . Cela couvre les mécanismes DI de base en termes de déclaration d'un point d'injection.
Maintenant, revenons à la question - avec l'avertissement que j'ai beaucoup plus d'expérience avec Spring qu'avec Guice.
Capacités d'entreprise dans Weld
- Mécanismes de configuration alternatifs ont une conception très propre dans JSR-299 et permettent des mécanismes de configuration en dehors du code Java (
beans.xml). - Les événements sont une chose très puissante et s'intègrent bien avec JMS. Je viens de trouver un Event Bus for Guice , mais je ne peux pas dire comment cela se compare.
- Les extensions portables sont un SPI qui peut être utilisé pour s'intégrer à la technologie existante ou pour envelopper le code hérité d'une manière propre.
Avantages/inconvénients
Remarque: je vais essayer d'ajouter quelques éléments ici plus tard, mais cette réponse est déjà plus longue que ce à quoi je m'attendais, désolé.
Soudure/CDI
- Standardisation: Si quelque chose est standardisé et qu'il y a une bonne implémentation, beaucoup de gens l'utiliseront. Exemple: étendues intégrées dans Weld fournit quelques étendues de plus que Guice ou Spring . Tous ces éléments peuvent être étendus, mais les cadres d'application s'appuieront plutôt sur des étendues standard s'ils sont utilisés par une grande communauté.
- Prise en charge des conteneurs: c'est similaire à l'élément précédent, mais un argument majeur pour l'adoption. Les principaux serveurs d'applications open source, tels que Glassfish et JBoss 6 fournissent un support CDI (voir ici ).
Guice/Spring
- Application réelle: La plupart des applications existantes utiliseront déjà Guice/Spring. Spring/Guice s'est toujours basé sur des normes et a fourni de nouvelles capacités là où aucune norme n'existait ou ne pouvait être utilisée. Si vous respectez les meilleures pratiques respectives, le cadre vous aidera à rendre votre application basée sur les normes et propre.
AOP et intercepteurs
C'est un sujet très discuté et je ne peux pas privilégier l'un plutôt que l'autre. Les deux mécanismes sont très puissants mais nécessitent au moins une compréhension minimale de l'architecture de l'application. Regardez aussi Decorators et le Events précédemment référencé. Il est préférable d'utiliser le bon outil, mais n'oubliez pas que si un développeur doit travailler avec l'un de ces mécanismes, c'est une bonne chose s'il comprend le concept.
Performances
Malheureusement, je n'ai pas encore pu examiner cela, mais il y a quelques règles que j'essaie de suivre, surtout lorsque j'utilise un framework qui vous donne beaucoup de fonctionnalités sans que vous le remarquiez:
- Dans la mesure du possible, préférez une seule étape de câblage à plusieurs recherches lors de l'exécution.
- Si possible, effectuez tout le câblage lors de l'initialisation de l'application.
- Toute étape d'interception ou proxy AOP ajoute quelques appels de méthode à la pile.
CDI (Weld) n'a pas encore été largement utilisé, il est donc difficile de faire une comparaison. Quelques points:
- CDI a été conçu en tenant compte de l'intégration avec EJB3, JSF et d'autres normes JavaEE. CDI a les extensions dites portables qui permettent aux bibliothèques tierces de s'intégrer au cycle de vie et au fonctionnement interne d'une implémentation CDI
- CDI a été conçu en tenant compte de tous les cas d'angle possibles, il est donc probable qu'il couvre tout ce dont vous avez besoin. Spring, Guice et Seam ont évolué vers un tel état, tandis que CDI utilise l'expérience de ces trois.
- à mon avis, les intercepteurs CDI ne seront pas en mesure de répondre à toutes les demandes auxquelles Spring AOP a répondu. Il en va peut-être de même pour Guice AOP. Vous ne pouvez pas définir d'intercepteur à l'aide de la syntaxe AspectJ.
- l'absence de définitions xml est à la fois un avantage et un inconvénient et certaines personnes (à juste titre dans certains cas) préfèrent la configuration xml.
- l'utilisation étendue des annotations qualificatives générera (à mon avis) de gros dégâts si elle n'est pas utilisée avec précaution.
CDI pour les utilisateurs de Guice est une belle comparaison.
La caractéristique la plus importante que CDI s'est opposée à Guice est qu'il s'agit d'une partie standard de Java EE 6.
L'importance de cela ne peut pas être sous-estimée, car cela signifie que CDI est la norme DI que vous devez utiliser lors du codage des applications Web.
Il y a quelque temps, j'ai jeté un œil aux technologies pour déterminer comment nous pourrions avoir une distribution de base standard - convenablement préparée - où nous pourrions ajouter des modules supplémentaires à volonté qui pourraient remplacer les fonctionnalités existantes sans avoir à changer les modules de base. C'est à dire. ajoutez un pot supplémentaire et la fonctionnalité s'activera automatiquement.
Il s'est avéré que la meilleure façon pour nous de le faire pour une base de code utilisée dans les applications de bureau et Web, était d'utiliser les annotations JSR-330 pour notre code, puis d'utiliser soit CDI ou Guice (SVN, bientôt très bientôt 3.0) comme moteur.
Après quelques projets, j'ai trouvé que j'aime mieux la configuration Guice que la magie opaque qui se passe dans Weld. De plus, j'ai trouvé que la façon de faire ce que nous voulons comme décrit ci-dessus avec Weld, je dois marquer la classe dans le pot supplémentaire comme @Alternative, puis mentionner dans beans.xml que je veux que la classe alternative soit appliquée (et ce n'est pas robuste contre refactoring).
Mais, dans l'ensemble, JSR-330 nous permet de faire quelque chose qui était très fastidieux et fragile auparavant (parce que new se lie si extrêmement étroitement), et c'est une grande victoire. Je peux fortement recommander d'examiner DI si vous avez un besoin comme celui-ci.
Un autre différenciateur est que CDI est très Java EE orienté. Il fournit un mécanisme pour coller les différents sous-systèmes Java EE ensemble).
C'est à dire. En annotant un bean avec @Named("book"), le bean devient connu dans le EL unifié (Expression Language) comme 'book'.
Ensuite, vous pouvez l'utiliser dans une page JSF par exemple:
<h:outputLabel value="Book title:" for="bookTitle"/>
<h:outputText id="bookTile" value="#{book.title}"/>
J'ai utilisé Guice dans une application sans serveur AWS Lambda. AWS recommande d'utiliser Guice ou Dagger sur Spring dans une fonction Lambda. Voir meilleures pratiques AWS Lambda
La raison principale est que Guice et Dagger sont des cadres plus petits et ont un temps de démarrage plus rapide, ce qui est essentiel dans Lambda.
Bien que l'OP n'ait pas mentionné Spring, Spring et CDI/weld sont destinés aux applications de niveau entreprise, qui nécessitent souvent des fonctionnalités supplémentaires fournies par ces frameworks. Par conséquent, pour les petites applications, qui ne nécessitent que DI, Guice ou Dagger serait optimale.