Printemps vs EJB. Spring peut-il remplacer les EJB?
Spring a été développé dès le début comme une alternative aux EJB. Vous pouvez donc utiliser Spring à la place des EJB.
S'il y a un "avantage" à utiliser des EJB, je dirais que cela dépend des compétences de votre équipe. Si vous ne possédez aucune expertise Spring et que vous possédez une grande expérience des EJB, alors rester avec EJB 3.0 est une bonne chose.
Les serveurs d'applications conçus pour prendre en charge le standard EJB peuvent, en théorie, être portés d'un serveur d'applications conforme Java EE à un autre. Toutefois, cela signifie que vous devez vous tenir à l'écart de toutes les extensions spécifiques au fournisseur qui vous bloquent. à un vendeur.
Relâchez facilement les ports entre les serveurs d'applications (WebLogic, Tomcat, JBOSS, etc.), car cela ne dépend pas d'eux.
Cependant, vous êtes enfermé dans Spring.
Spring encourage OO) les pratiques de conception (interfaces, couches, séparation des problèmes, par exemple) qui profitent à tous les problèmes qu’elles touchent, même si vous décidez de basculer vers Guice ou un autre cadre d’ID.
Mise à jour: Cette question et cette réponse datent de cinq ans en 2014. Il faut dire que le monde de la programmation et du développement d'applications a beaucoup évolué au cours de cette période.
Ce n'est plus juste un choix entre Java ou C #, Spring ou EJB. Avec vert.x , il est possible d'éviter Java EE Vous pouvez écrire des applications polyglottes hautement évolutives sans serveur d'applications.
Mise à jour: C'est mars 2016 maintenant. Spring Boot offre un moyen encore meilleur d’écrire des applications sans Java EE. Vous pouvez créer un fichier JAR exécutable et l’exécuter sur une machine virtuelle Java.
Je me demande si Oracle continuera à prendre en charge le Java Spéc. EE. Les services Web ont pris le relais pour les EJB. La solution EJB est morte. (À mon avis.)
Tout d’abord, laissez-moi le dire clairement, je ne dis pas que vous ne devriez pas utiliser Spring, mais, comme vous demandez des avantages, voici au moins deux d’entre eux:
L'EJB 3 est un standard alors que Spring n'est pas (c'est un standard de facto mais ce n'est pas la même chose) et cela ne changera pas dans un avenir prévisible. Bien que vous puissiez utiliser la structure Spring avec n’importe quel serveur d’applications, les applications Spring sont verrouillées à la fois dans Spring et dans les services spécifiques que vous choisissez d’intégrer dans Spring.
L'infrastructure Spring repose sur les serveurs d'applications et les bibliothèques de services. Le code d'intégration de service (par exemple, les modèles d'accès aux données) réside dans la structure et est exposé aux développeurs d'applications. En revanche, l'infrastructure EJB 3 est intégrée au serveur d'applications et le code d'intégration de service est encapsulé derrière une interface. Les fournisseurs d'EJB 3 peuvent ainsi optimiser les performances et l'expérience des développeurs en travaillant au niveau du serveur d'applications. Par exemple, ils peuvent lier étroitement le moteur JPA à la gestion des transactions JTA. Un autre exemple est la prise en charge du clustering, transparente pour les développeurs EJB 3.
L'EJB 3 n'est pas parfait, cependant, certaines fonctionnalités lui manquent (par exemple, l'injection de composants non gérés comme des simples POJO).
Les points de Pascal sont valables. Il y a cependant les suivants en faveur du printemps.
La spécification EJB est en fait un peu lâche et, par conséquent, différents comportements peuvent être observés avec différents serveurs d'applications. Ce ne sera pas vrai dans la plupart des cas, bien sûr, mais j'ai eu un tel problème pour certains "coins sombres".
Le printemps offre de nombreux atouts supplémentaires, tels que test de printemps, AOP, MVC, intégration de JSF, etc. EJB en possède quelques-uns (des intercepteurs, par exemple), mais à mon avis, ils ne sont pas très développés.
En conclusion, cela dépend principalement de votre cas exact.