CDI est-il un bon remplacement de Spring?
Nous prévoyons d'écrire une application Web à partir de zéro, il a été décidé d'utiliser la dernière édition de Glassfish qui est conforme à Java EE 6 standard, nous analysons donc si CDI peut être utilisé au lieu du printemps.
Peut-on dire que CDI pourrait remplacer le printemps?
CDI signifie "context and dependency injection", tandis que Spring est un écosystème complet autour d'un conteneur d'injection de dépendances. Pour comparer les deux, vous devez différencier la comparaison.
L'injection de dépendances est gérée par les deux conteneurs. La principale différence est le fait que CDI gère DI de manière dynamique (aka: avec état) - cela signifie que les dépendances sont résolues à temps d'exécution. L'approche de Spring est statique - cela signifie que les composants sont câblés ensemble à au moment de la création. Bien que la méthode CDI puisse sembler un peu inhabituelle à première vue, elle est de loin supérieure et offre des options beaucoup plus nombreuses et avancées (j'écris ceci avec l'arrière-plan de deux applications CDI productives).
Si vous regardez l'écosystème , la situation est différente: le printemps est livré avec beaucoup de pots (> 150 ), tandis que CDI est assez petit en soi. Une utilisation CDI typique serait à l'intérieur d'un Java EE 6, mais vous pouvez facilement le faire fonctionner dans un moteur de servlet ou même Java SE. Cela signifie que l'utilisation de CDI ne fait aucune hypothèse sur l'utilisation de Hibernate, JPA, EJB ou autre - c'est à vous de décider.
Si vous avez besoin de plus de fonctionnalités, CDI est livré avec le concept d'extensions portables (ce qui en soi rend l'API digne de ce nom). Des modules d'extension indépendants comme Apache CODI et Seam 3 existent et couvrent des sujets tels que la sécurité, le courrier, les rapports et plus encore.
Pour résumer: le CDI ne ressemble en rien à un "remplacement" de l'écosystème Spring, c'est plutôt une amélioration par rapport au mécanisme d'injection de dépendance de Spring. Cela fait partie de Java EE 6, donc si vous êtes sur un GlasFish avec Java EE 6, vous devriez certainement opter pour CDI. À mes yeux, votre question est plutôt: Puis-je remplacer Spring par Java EE 6? Je suppose que ma réponse est assez évidente ;-)
Jetez un oeil à Weld pour bien démarrer ...
Le printemps est plus qu'un simple conteneur d'injection de dépendance. Il dispose également d'outils pour AOP, de modèles à utiliser avec JPA, SQL, etc. et bien plus encore.
Cependant, CDI peut être utilisé en remplacement de l'API DI de Spring.
J'utilise Apache OpenWebBeans comme implémentation CDI et MyFaces CODI comme extension portable pour plusieurs projets. J'en suis très content et je n'ai eu aucun problème avec ça. OpenWebBeans manque actuellement un peu de documentation, mais si vous ne pouvez pas faire fonctionner quelque chose, il est assez facile d'utiliser les archétypes Maven fournis par MyFaces pour générer des projets simples avec toutes les dépendances nécessaires ou vous le demandez sur la liste de diffusion. C'est génial si vous travaillez uniquement sur votre application et que vous n'êtes pas bloqué par des bugs désagréables. J'ai aussi fait beaucoup de projets avec Spring. C'est bon, mais si vous demandez ce que j'utiliserais pour le prochain projet, la réponse claire est OpenWebBeans et CODI! Je préfère OpenWebBeans à Weld car OpenWebBeans est très adoptable, c'est génial car vous pouvez personnaliser plus ou moins tout ce qui n'est pas couvert par l'API/SPI CDI officielle et la performance runtimeperformance est meilleure. Et après le premier projet, je ne remettrai jamais en question CODI car il est très stable, ils ont des versions régulières et la plupart d'entre eux ont apporté de nouvelles fonctionnalités qui améliorent beaucoup la productivité. CODI est à mon humble avis l'endroit qui est le plus stable et où la plupart des innovations proviennent de l'ensemble du pays CDI.
Pour répondre à votre question: Pour moi, CDI a complètement remplacé Spring, mais vous avez besoin d'extensions portables qui comblent les lacunes. Le CDI en standard n'a jamais eu l'intention de tout résoudre et certaines parties comme les conversations sont cassées par conception. La bonne nouvelle est que vous avez de grands projets comme MyFaces CODI. CODI corrige presque tous ces problèmes.