Printemps contre EJB. Spring peut-il remplacer EJB? [fermé]

96

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?

cometta
la source

Réponses:

201

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.)

duffymo
la source
7
À mon avis, «verrouiller» est une expression trop forte pour décrire le printemps. Après tout, Spring est conçu pour tout coller ensemble, pas pour les remplacer, vous pouvez toujours choisir ce que vous souhaitez intégrer. De plus, tout a des verrous, même le plus simple Apache Commons nous enferme, mais nous l'utilisons toujours tous les jours.
Christopher Yang
3
Il n'existe pas de fournisseur alternatif à VMWare / Spring comme vous pouvez choisir entre les plates-formes Oracle, Red Hat et IBM pour Java EE. C'est tout ce que je voulais dire. Ce n'est pas un commentaire sur la capacité ou l'utilité de Spring. Je l'aime beaucoup. Je l'utilise tous les jours et je dors la nuit.
duffymo
1
@ChristopherYang c'est correct. Je veux dire, "Java" serait un verrou de fournisseur. Donc, finalement, nous devons simplement arrêter de nous disputer et faire quelque chose. :-)
cbmeeks
4
Cette question remonte à près de cinq ans. Personnellement, je pense que les EJB sont des technologies obsolètes qui ont perdu à tous points de vue les services Web HTTP. Victoire simple et ouverte. Donnez-moi les services REST et vous pourrez conserver vos EJB. Spring les soutient bien. C'est là que le monde est allé.
duffymo
1
Merci pour la réponse. Il suffit de rechercher les avantages en évaluant le meilleur (SPRING, EJB 3.x) pour la migration à partir d'une application EJB 2.1 existante. Encore une question, EJB 3.x prend également en charge le WebService. Alors, pourrions-nous bénéficier de JNDI / RMI pour la distribution d'applications Java et WS pour d'autres applications?
noboundaries
48

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).

Pascal Thivent
la source
1
Réponse éducative, mais je me demande pourquoi / quand vous devez injecter un simple POJO au lieu d'en initialiser un nouveau?
Ömer Faruk Almalı
4
À des fins de test.
Philip
22

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.

Bozho
la source
Peut-être que quelque chose comme Spring n'a besoin que d'un moteur de servlet serait plus précis (EJB peut être utilisé dans n'importe quel conteneur JEE, moteur de servlet! = Conteneur JEE).
Pascal Thivent
1
Eh bien, techniquement, Spring ne nécessite pas non plus de moteur de servlet. Par exemple, spring-test utilise un contexte en mémoire.
Bozho
3
Eh bien, techniquement, les EJB ne nécessitent pas non plus de conteneur autonome si vous choisissez cette option. Depuis EJB 3.1, il existe l' EJBContainer.createEJBContainer()API standard pour utiliser un conteneur intégré. Donc, encore, votre déclaration est fausse.
Pascal Thivent
ok, 3.1 est assez nouveau et évidemment j'ai oublié les ajouts. Supprimé ce point de ma réponse.
Bozho
-30

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.

sasi
la source
8
vous vous trompez totalement, désolé
Jakub H
2
désolé @sasi ce n'est même pas près d'une réponse correcte ou agréable .......
Prakash
4
"Le printemps n'existerait pas sans EJB." Mec, tu es pour de vrai? Avez-vous déjà dans votre vie utilisé le "\ @Stateless" dans la déclaration d'un EJB, ou utilisé l'annotation \ @EJB pour l'injection? Pensez-vous que cela fonctionnerait dans Jetty ou Tomcat? Comment pensez-vous que les transactions sont gérées au printemps? Vous savez que vous pouvez déployer une application Spring dans un conteneur de servlet, n'est-ce pas?
99Sono
Désolé, mais vous n'avez pas une compréhension bien structurée des deux, les EJB dans le cadre de Java EE et Spring comme principe de convention sur configuration. En réalité, si vous ne creusez pas dans les profondeurs, vous finirez peut-être par penser qu'ils sont quelque peu identiques ou liés ou quoi que ce soit de ce genre. Pourquoi? ils ont tous les deux des similitudes comme l'injection et mais la différence entre eux est énorme. Il est vrai que Spring est né comme une alternative aux EJB dans le passé en raison de la complexité d'EJB, mais c'était le cas. Assez bien pendant le temps de Java EE 5 (EJB 3) a été retouché en faisant aussi comme le printemps faisait avec leur COC
Ishimwe Aubain Consolateur