Google Guice vs. JSR-299 CDI / Weld

Question

Weld, l'implémentation de référence de JSR-299 Contexts and Dependency Injection, se considère comme une sorte de successeur de Spring et Guice.

CDI a été influencé par un certain nombre de frameworks Java existants, notamment Seam, Guice et Spring. Cependant, CDI a son propre caractère, très distinct : plus sûr que Seam, plus étatique et moins centré sur XML que Spring, plus capable de fonctionner sur le web et dans les applications d'entreprise que Guice. Mais il n'aurait pu être aucun de ces éléments sans l'inspiration des cadres mentionnés et sans la collaboration et le travail acharné du groupe d'experts (EG) JSR-299.

http://docs.jboss.org/weld/reference/latest/en-US/html/1.html

Qu'est-ce qui rend Weld plus apte aux applications d'entreprise par rapport à Guice ? Y a-t-il des avantages ou des inconvénients par rapport à Guice ? Que pensez-vous de Guice AOP par rapport aux intercepteurs Weld ? Qu'en est-il des performances ?

Mon choix

En fin de compte, j'ai décidé d'utiliser Guice parce que j'aime le modèle de programmation propre qui est livré presque sans annotations à part @Inject par défaut. Il est beaucoup plus facile d'utiliser des librairies externes avec Guice qu'avec CDI. La POA est également assez simple avec Guice.

Answer 1

Avant d'essayer de répondre à votre question, permettez-moi d'ajouter un élément d'information important : JSR 330 ( @Inject ) a été normalisé par les projets Guice et Spring ( annonce de mai 2009 ) et est en train de réutilisé dans la JSR 299 . Cela couvre les mécanismes DI de base en termes de déclaration d'un point d'injection.

Revenons maintenant à la question - en précisant que j'ai beaucoup plus d'expérience avec Spring qu'avec Guice.

Capacités d'entreprise à Weld

• Mécanismes de configuration alternatifs ont une conception très propre dans la JSR-299 et permettent des mécanismes de configuration en dehors du code Java ( beans.xml ).
• Événements sont très puissants et s'intègrent parfaitement à JMS. Je viens de trouver un Bus événementiel pour Guice mais je ne peux pas dire comment cela se compare.
• Extensions portables sont un SPI qui peut être utilisé pour intégrer la technologie existante ou envelopper le code hérité de manière propre.

Avantages / Inconvénients

Note : J'essaierai d'ajouter quelques éléments plus tard, mais cette réponse est déjà plus longue que prévu, désolé.

• Soudure/CDI

  • Normalisation : Si quelque chose est normalisé et qu'il existe une bonne mise en œuvre, beaucoup de gens l'utiliseront. Exemple : Scopes intégrés dans Weld fournissent un peu plus de possibilités que les Guice o Printemps . Tous ces éléments peuvent être étendus, mais les cadres d'application préféreront s'appuyer sur des champs d'application standard s'ils sont utilisés par une large communauté.
  • Soutien aux conteneurs Ce point est similaire au précédent, mais constitue un argument majeur en faveur de l'adoption. Les principaux serveurs d'applications open source, tels que Glassfish et JBoss 6, prennent en charge le CDI (cf. ici ).

• Guide/Printemps

  • Application réelle : La plupart des applications existantes utiliseront déjà Guice/Spring. Spring/Guice se sont toujours appuyés sur des standards et ont fourni de nouvelles capacités là où aucun standard n'existait ou ne pouvait être utilisé. Si vous suivez les meilleures pratiques respectives, le framework vous aidera à rendre votre application propre et basée sur des standards.

AOP et intercepteurs

Il s'agit d'un sujet très discuté, et je ne peux pas privilégier l'un ou 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. Consultez également Décorateurs et la référence précédente Événements . Il est préférable de choisir le bon outil, mais n'oubliez pas que si un développeur doit travailler avec l'un de ces mécanismes, il est bon qu'il en comprenne le concept.

Performance

Malheureusement, je n'ai pas encore pu me pencher sur la question, mais il y a quelques règles que j'essaie de suivre, surtout lorsque j'utilise un framework qui vous offre de nombreuses fonctionnalités sans que vous vous en rendiez compte :

• Dans la mesure du possible, préférez une seule étape de câblage à plusieurs recherches au moment 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.

Answer 2

Le 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 possède des extensions dites portables qui permettent à des 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 de figure 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-là.
• À 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 un intercepteur en utilisant 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 va (à mon avis) générer de gros dégâts si elle n'est pas utilisée avec précaution.

Answer 3

CDI pour les utilisateurs de Guice est une bonne comparaison.

Answer 4

La caractéristique la plus importante de CDI, par rapport à Guice, est qu'il s'agit d'un outil de gestion de l'information. standard qui fait partie de Java EE 6.

L'importance de ce point ne doit pas être sous-estimée, car cela signifie que le CDI est la norme DI que vous devez utiliser pour coder des applications Web.

Il y a quelque temps, j'ai examiné les technologies afin de déterminer comment nous pourrions avoir une distribution de base standard - convenablement préparée - à laquelle nous pourrions ajouter des modules supplémentaires à volonté qui pourraient remplacer les fonctionnalités existantes sans avoir à modifier les modules de base. C'est-à-dire qu'il suffit d'ajouter un jar supplémentaire pour que la fonctionnalité s'active automatiquement.

Il s'est avéré que la meilleure façon de procéder pour une base de code utilisée à la fois dans des applications de bureau et des applications Web était d'utiliser les annotations JSR-330 pour notre code, puis d'utiliser CDI ou Guice (SVN, bientôt disponible en version 3.0) comme moteur.

Après quelques projets, j'ai constaté que je préférais la configuration Guice à la magie opaque de Weld. De plus, j'ai découvert que la façon de faire ce que nous voulons comme décrit ci-dessus avec Weld, je dois marquer la classe dans le jar supplémentaire comme @Alternative, et ensuite mentionner dans beans.xml que je veux que la classe alternative soit appliquée (et ce n'est pas robuste contre le refactoring).

Mais, dans l'ensemble, la JSR-330 nous permet de faire quelque chose qui était très fastidieux et fragile auparavant (parce que new se lie de façon extrêmement serrée), et c'est une grande victoire. Je vous recommande vivement de vous intéresser à DI si vous avez un besoin de ce genre.

Answer 5

Un autre facteur de différenciation est que CDI est très orienté vers Java EE. Il fournit un mécanisme pour colle les différents Sous-systèmes Java EE ensemble.

Ie. En annotant un haricot avec @Named("book") le haricot devient connu dans le langage EL (Expression Language) unifié sous le nom de book '.

Vous pouvez ensuite l'utiliser dans une page JSF par exemple :

    <h:outputLabel value="Book title:" for="bookTitle"/>
    <h:outputText id="bookTile" value="#{book.title}"/>