Depuis Spring est capable d'utiliser des transactions comme EJB . Pour moi, Spring est en mesure de remplacer l'exigence d'utiliser EJB. Quelqu'un peut-il me dire quels sont les avantages supplémentaires de l'utilisation d'EJB?
Réponses:
Spring a été développé comme une alternative aux EJB dès sa création, donc la réponse est bien sûr que vous pouvez utiliser Spring à la place des EJB.
S'il y a un "avantage" à utiliser les EJB, je dirais que cela dépendra des compétences de votre équipe. Si vous n'avez aucune expertise Spring, et beaucoup d'expérience EJB, alors peut-être rester avec EJB 3.0 est une bonne chose.
Les serveurs d'applications écrits pour prendre en charge la norme EJB peuvent, en théorie, être portés d'un serveur d'applications Java EE conforme à un autre. Mais cela signifie rester à l'écart de toutes les extensions spécifiques aux fournisseurs qui vous enferment dans un seul fournisseur.
Spring se connecte facilement entre les serveurs d'applications (par exemple, WebLogic, Tomcat, JBOSS, etc.) car cela ne dépend pas d'eux.
Cependant, vous êtes enfermé dans Spring.
Spring encourage les bonnes pratiques de conception OO (par exemple, les interfaces, les couches, la séparation des préoccupations) qui profitent à tout problème qu'ils touchent, même si vous décidez de passer à Guice ou à un autre framework DI.
Mise à jour: Cette question et 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 changé pendant cette période.
Ce n'est plus seulement un choix entre Java ou C #, Spring ou EJB. Avec vert.x, il est possible d'éviter complètement Java EE. Vous pouvez écrire des applications polyglottes hautement évolutives sans serveur d'applications.
Mise à jour: Nous sommes en mars 2016 maintenant. Spring Boot offre un moyen encore meilleur d'écrire des applications sans serveurs d'applications Java EE. Vous pouvez créer un JAR exécutable et l'exécuter sur une machine virtuelle Java.
Je me demande si Oracle continuera à prendre en charge la spécification Java EE. Les services Web ont pris le relais des EJB. La solution EJB est morte. (Juste mon avis.)
Tout d'abord, laissez-moi le dire clairement, je ne dis pas que vous ne devriez pas utiliser Spring mais, parce que vous demandez certains avantages, en voici au moins deux:
EJB 3 est un standard alors que Spring ne l'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 le framework Spring avec n'importe quel serveur d'applications, les applications Spring sont verrouillées à la fois dans Spring lui-même et dans les services spécifiques que vous choisissez d'intégrer dans Spring.
Le framework Spring se trouve au-dessus des serveurs d'applications et des 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 le framework et est exposé aux développeurs d'applications. En revanche, le framework EJB 3 est intégré au serveur d'application et le code d'intégration de service est encapsulé derrière une interface. Les éditeurs d'EJB 3 peuvent ainsi optimiser les performances et l'expérience des développeurs en travaillant au niveau du serveur d'application. Par exemple, ils peuvent lier étroitement le moteur JPA à la gestion des transactions JTA. Un autre exemple est la prise en charge du clustering qui est transparente pour les développeurs EJB 3.
EJB 3 n'est cependant pas parfait, il manque encore certaines fonctionnalités (par exemple l'injection de composants non gérés comme de simples POJO).
Les points de Pascal sont valides. Il y a cependant ce qui suit en faveur du printemps.
La spécification EJB est en fait un peu lâche, et donc 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».
Spring a beaucoup de bonus supplémentaires, comme Spring-test, AOP, MVC, intégration JSF, etc. EJB en a certains (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.
EJBContainer.createEJBContainer()API standard pour utiliser un conteneur intégré. Donc, encore, votre déclaration est fausse.
Spring est destiné à compléter l'EJB, pas à le remplacer. Le printemps est une couche au-dessus de l'EJB. Comme nous le savons, le codage d'EJB se fait à l'aide de l'API, ce qui signifie que nous devons tout implémenter dans les API à l'aide du framework Spring. Nous pouvons créer un code passe-partout, puis il suffit de prendre cette plaque, d'y ajouter des trucs, puis tout est fait. En interne, Spring est connecté à EJB - Spring n'existerait pas sans EJB.
Le principal avantage de l'utilisation de Spring est qu'il n'y a aucun couplage entre les classes.