Devrais-je utiliser EJB3 ou Spring pour ma couche métier?

Question

Mon équipe développe un nouveau produit orienté service avec une interface Web. Au cours des discussions sur les technologies que nous allons utiliser, nous avons décidé d’exécuter un serveur d’application JBoss, une interface Flex (avec le déploiement possible de postes de travail utilisant Adobe AIR) et des services Web permettant d’interfacer le client et le serveur.

La technologie de serveur à utiliser pour notre logique métier est dans l'impasse. L’argument majeur est entre EJB3 et Spring, nos principales préoccupations étant l’évolutivité et les performances, ainsi que la maintenabilité de la base de code.

Voici mes questions:

1. Quels sont les arguments pour ou contre EJB3 vs Spring?
   • À quels pièges puis-je m'attendre avec chacun?
   • Où puis-je trouver des informations de référence fiables?

Answer 1

Il n'y aura pas beaucoup de différence entre EJB3 et Spring en fonction des performances. Nous avons choisi Spring pour les raisons suivantes (non mentionnées dans la question):

• Spring conduit l’architecture dans une direction qui prend plus facilement en charge le test unitaire. Par exemple, injectez un objet DAO factice pour tester votre couche métier ou utilisez l'objet MockHttpRequest de Spring pour tester un servlet. Nous maintenons une configuration Spring distincte pour les tests unitaires qui nous permet d’isoler les tests des couches spécifiques.
• La compatibilité était un pilote primordial. Si vous devez prendre en charge plusieurs serveurs d'applications (ou si vous souhaitez éventuellement pouvoir passer de JBoss à Glassfish, etc.), vous emporterez essentiellement votre conteneur (Spring) avec vous, plutôt que de vous fier à la compatibilité entre les différentes implémentations du logiciel. Spécification EJB3.
• Spring autorise les choix technologiques en matière de persistance, d’accès distant aux objets, etc. Nous utilisons également un serveur frontal Flex et le protocole hessien pour les communications entre Flex et Spring.

Answer 2

L’écart entre EJB3 et Spring est nettement plus petit qu’il ne l’était, clairement. Cela dit, l’un des inconvénients de EJB3, c’est que vous ne pouvez vous injecter que dans un haricot, ce qui vous permet de transformer des composants en haricots qui n’ont pas besoin d’être.

L’argument à propos des tests unitaires n’a plus guère d’importance à présent - EJB3 est clairement conçu pour être plus facilement testable par unité.

L'argument de compatibilité ci-dessus n'a également aucune importance: que vous utilisiez EJB3 ou Spring, vous dépendez toujours d'implémentations fournies par des tiers, telles que des gestionnaires de transactions, JMS, etc.

Cependant, ce qui me serait utile, c’est le soutien de la communauté. En travaillant sur un projet EJB3 l'année dernière, peu de gens l'utilisaient et parlaient de leurs problèmes. Spring, à tort ou à raison, est extrêmement répandu, particulièrement dans l’entreprise, et il est donc plus facile de trouver une personne qui a le même problème que vous essayez de résoudre.

Answer 3

Quels sont les arguments pour ou contre EJB3 vs Spring? Le printemps innove toujours et reconnaît les contraintes du monde réel. Spring offrait simplicité et élégance aux serveurs d’applications Java 1.4 et ne nécessitait pas de version de la spécification J2EE à laquelle personne n’avait accès en 2004 - 2006. Il s’agit là d’un débat presque religieux dans lequel vous pouvez être entraîné - Spring + abstraction + spécifications open source versus Java Enterprise Edition (Java EE) 5.0.

Je pense que Spring complète davantage la concurrence avec les spécifications Java EE. Alors que les caractéristiques qui étaient autrefois uniques à Spring continuent à être intégrées à la spécification, beaucoup soutiendront que l'EJB 3 offre un ensemble de fonctionnalités "assez correct" pour la plupart des applications de gestion internes.

À quels pièges puis-je m'attendre avec chacun? Si vous traitez ce problème comme un problème de persistance (Spring + JPA) par rapport à EJB3, vous ne faites vraiment pas ce choix.

Où puis-je trouver des informations de référence fiables? Je n'ai pas suivi les résultats des tests de performances spécifiques pendant une période donnée, mais ils étaient populaires. pour un moment. Il semble que chaque fournisseur (IBM, JBOSS, Oracle et Sun) soit de moins en moins intéressé par un serveur conforme. Les listes obtiennent de plus en plus courte des vendeurs certifiés à partir de 1.3, 1.4. 1.5 Java Enterprise Edition. Je pense que l'époque d'un serveur géant entièrement conforme à toutes les spécifications est révolue.

Answer 4

Je recommanderais certainement EJB3 au printemps. Nous trouvons qu’il est plus simple, plus agréable à coder et mieux supporté. Dans le passé, j’ai utilisé Spring et je l’ai trouvé très déroutant, et pas aussi bien documenté que EJB3 (ou JPA, je suppose, à la fin de la journée)

1. À partir de EJB3, vous n’avez plus à traiter de fichiers de configuration externes, et vous n’annotez qu’un seul POJO par table de base de données. Ce POJO peut être transmis à votre niveau Web sans aucun problème. Les IDE tels que Netbeans peuvent même générer automatiquement ces POJO pour vous. Nous utilisons maintenant EJB3 comme back-end pour de nombreuses applications à grande échelle et nous n’avons remarqué aucun problème de performances. Vos Session Beans peuvent être facilement exposés en tant que services Web que vous pourriez exposer à votre interface Flex. Les beans session sont faciles à verrouiller au niveau de la méthode ou de la classe pour attribuer des rôles, etc. si besoin est.

Je ne peux pas trop parler du printemps, je ne l'ai essayé que pendant quelques semaines. Mais mon impression générale était très mauvaise. Cela ne veut pas dire que ce soit un mauvais cadre, mais notre équipe a trouvé que EJB3 était le meilleur pour la couche persistance / métier.

Answer 5

J'ai tendance à préférer Spring à EJB3, mais je vous recommanderais quelle que soit l'approche choisie, essayez de vous en tenir à l'écriture de POJO et utilisez autant que possible les annotations standard, comme les annotations JSR telles que @PostConstruct, @PreDestroy et @Resource qui fonctionnent. avec EJB3 ou Spring pour que vous puissiez choisir le cadre que vous préférez.

par exemple. vous pouvez choisir un projet utilisant Guice à la place de l'IoC.

Si vous souhaitez utiliser l'injection de pré-requête, comme dans une application Web, vous constaterez peut-être que Guice est un peu plus rapide que Spring pour l'injection de dépendances.

Les beans session se résument principalement à l'injection de dépendance et aux transactions; donc EJB3 et Spring sont un peu similaires pour cela. Spring a l'avantage sur une meilleure injection de dépendance et des abstractions plus agréables pour des tâches telles que JMS

Answer 6

J'ai utilisé une architecture très similaire dans le passé. Spring + Java 1.5 + Actionscript 2/3 une fois combinés à Flex Data Services ont rendu le code très facile (et amusant!). Cependant, un frontal Flex signifie que vous avez besoin d’ordinateurs clients suffisamment puissants.

Answer 7

En ce qui concerne votre question:

  

Quels sont les arguments pour ou contre EJB3 vs Spring?

Je suggère de lire la réponse des experts: UNE RÉPONSE À: EJB 3 ET ANALYSE COMPARATIVE DU PRINTEMPS par Mark Fisher . Lisez les commentaires pour trouver les remarques de Reza Rahman (EJB 3.0).

Answer 8

Un autre avantage en faveur du printemps est que la plupart des autres outils / cadres existants prennent mieux en charge l'intégration avec Spring, la plupart d'entre eux utilisent également Spring en interne (par exemple, activemq, camel, CXF, etc.).

Il est également plus mature et contient beaucoup plus de ressources (livres, articles, meilleures pratiques, etc.) & amp; développeurs expérimentés disponibles que pour EJB3.

Answer 9

Je pense que l’EJB est une bonne technologie de composant mais pas un bon cadre. Spring est le meilleur cadre disponible à ce jour. Je dois donc considérer Spring comme la meilleure implémentation de JEE dans le sens d’un cadre et ma recommandation est d’utiliser printemps dans chaque projet, ce qui nous donne la souplesse nécessaire pour intégrer facilement toute technologie de composant.