EJB 3.1 ou Spring 3 .. Quand choisir lequel?
EJB a réalisé de nombreuses améliorations dans les versions 3.x, Spring est également couramment utilisé et la version 3 est une bonne alternative.
Il existe de nombreux articles sur le Web, mais aucune comparaison exacte entre ejb3x et spring3x .. Avez-vous des idées à leur sujet, dans des exemples concrets, lequel est le meilleur dans quelles conditions?
Par exemple, nous voulons séparer la base de données et le serveur, ce qui signifie que notre application sera sur un serveur, notre base de données sera dans un autre serveur. EJB remoting vs Cluster4Spring etc?
Faire tout @Annotation est toujours bon? configuration jamais nécessaire?
Pour votre cas d'utilisation où l'application s'exécute sur un serveur et la base de données s'exécute sur un autre, le choix entre EJB et Spring n'est pas pertinent. Toutes les plates-formes prennent en charge cela, que ce soit une application Java SE, un simple conteneur de servlet comme Tomcat ou Jetty, PHP, Ruby on Rails, ou autre).
Vous n'avez besoin d'aucune sorte de télécommande explicite pour cela. Il vous suffit de définir une source de données, de fournir l'URL où réside votre serveur de base de données et c'est tout.
Cela dit, EJB et Spring Beans facilitent le travail avec les sources de données. Ils vous aident à définir une source de données, à l'injecter dans des beans et à gérer les transactions qui leur sont associées.
Des deux, EJB (et Java EE en général) est plus léger et adhère davantage à la convention sur le principe de configuration. Spring nécessite plus de verbosité pour obtenir les mêmes choses et dépend beaucoup des fichiers XML ce qui peut rapidement devenir très gros et difficile à manier. Le revers de la médaille est que le printemps peut être moins magique et vous pouvez vous sentir plus en contrôle après avoir tout expliqué.
Un autre problème est la façon dont EJB et Spring sont développés.
EJB est gratuit (comme dans la bière gratuite), open source et non propriétaire. Il existe des implémentations d'EJB réalisées par des organisations à but non lucratif (Apache), des sociétés open source (Redhat/JBoss) et des entreprises fermées profondément commerciales (IBM). Personnellement, j'éviterais ce dernier, mais à chacun le sien.
Spring, en revanche, est gratuit et open-source, mais fortement propriétaire. Il n'y a qu'une seule entreprise qui fabrique Spring et c'est Springsource. Si vous n'êtes pas d'accord avec Rod, alors bonne chance pour vous. Ce n'est pas nécessairement une mauvaise chose, mais une différence dont vous voudrez peut-être être conscient.
Faire tout @Annotation est toujours bon? configuration jamais nécessaire?
C'est vraiment un débat sans fin. Certains soutiennent que XML est difficile à maintenir, d'autres soutiennent que les annotations polluent un modèle POJO par ailleurs pur.
Je pense que l'annotation d'un bean comme étant un bean sans état EJB (@Stateless) ou une entité JPA (@Entity) se fait plus proprement à l'aide d'annotations. Il en va de même pour les injections de dépendance @EJB ou @Inject. D'un autre côté, je préfère que les requêtes nommées JPQL soient dans des fichiers XML au lieu d'annotations et que les injections qui représentent des données de configuration pures (comme une valeur maximale pour quelque chose) soient également en XML.
Dans Java EE, chaque annotation peut également être spécifiée en XML. Si à la fois l'annotation et l'équivalent XML sont présents, le XML annule l'annotation. Cela rend très pratique le début d'une annotation pour le cas par défaut, mais remplacez-le plus tard via XML pour un cas d'utilisation spécifique.
La préférence actuelle dans Java EE semble être plus vers des annotations (simples) combinées avec une grande quantité de convention sur la configuration.
La vraie question que vous devriez vous poser est CDI/EJB ou Spring
Ce n'est souvent pas Spring vs EJB, mais Spring vs Java EE. EJB lui-même se compare aux Spring Beans. Les deux sont une sorte de beans gérés exécutés à l'intérieur d'un conteneur (le conteneur EJB resp. Le conteneur Spring) ).
Globalement, les deux technologies sont assez similaires. Reza Rahman a fait une excellente comparaison entre les deux il y a quelque temps.
Les EJB sont plus avantageux en raison de la standardisation. Si vous travaillez avec une application légère, je pense que choisir Spring est très bien, mais si vous pensez que votre application sera volumineuse et nécessitera beaucoup d'accès à la mémoire et aux connexions de données, vous pouvez envisager de commencer votre développement avec des EJB. La principale raison étant le clustering et l'équilibrage de charge sont intégrés dans le framework EJB.
Dans un environnement EJB, lorsqu'une EAR ('E'nterprise' AR'chive) est déployée, elle peut être déployée avec plusieurs beans EJBs dont chacun pourrait avoir un objectif spécifique. Supposons que vous ayez écrit un bean pour la gestion des utilisateurs et un autre bean pour la gestion des produits. Peut-être qu'un jour, vous constaterez que vos services utilisateurs dépassent largement les services d'accès à vos produits et que vous souhaitez déplacer votre bean utilisateur vers un serveur différent sur une machine différente. Cela peut en fait être fait au moment de l'exécution sans modifier votre code. Les beans peuvent être déplacés entre les serveurs et les bases de données, pour s'adapter au clustering et à l'équilibrage de la charge/des données sans affecter vos développeurs ou vos utilisateurs car la plupart d'entre eux peuvent être configurés au niveau du déploiement.
Une autre raison de soutenir une norme est de savoir que la plupart des grands fournisseurs tiers la soutiendront probablement, ce qui entraînera moins de problèmes lors de l'intégration avec une nouvelle norme/service/technologie - et avouons-le, ceux-ci se présentent comme de nouvelles saveurs de crème glacée. Et si c'est dans une spécification publique, les nouvelles start-up ou les développeurs aimables peuvent créer une version open source.
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html
Il est très regrettable que même les concepteurs ou programmeurs les plus intelligents ne puissent pas prédire laquelle de leurs fonctionnalités pourrait ou non être adoptée par la communauté de développement, ce qui est la principale raison pour laquelle le logiciel devient gonflé ... Java EE c'est définitivement ça!
Choisissez l'un ou l'autre, mais pas les deux.
Ma préférence personnelle est le printemps. J'ai utilisé des projets avec beaucoup de succès au cours des six dernières années. Il est aussi solide que n'importe quel logiciel.
Spring peut fonctionner avec les EJB si vous choisissez de les avoir dans votre application, mais je ne pense pas que l'inverse soit vrai.
Je recommanderais des machines physiques distinctes pour les serveurs Web, d'applications et de bases de données si vous en avez les moyens.
Spring peut fonctionner avec plusieurs options de communication à distance, notamment SOAP et REST services Web. La comparaison des beans Spring avec EJB dépasse le cadre de cette question. ne vois pas ce que cela a à voir avec votre implémentation. Si vous utilisez les services Spring POJO, ils sont en mémoire plutôt que de nécessiter un autre saut de réseau comme des EJB distants. Pensez à la loi de Fowler sur les objets distribués: "Ne pas". Présentez seulement latence avec raison.
Je mentionnerais ici les tests unitaires. Dans une application Web commune (contrôleur-> service-> données -> ...-> vue) EJB et Spring fournissent tous deux un résultat similaire, mais Spring offre des tests plus faciles.
Dans mon humble expérience, la façon dont vous vous développez est différente sous deux aspects:
- Test unitaire (victoires de printemps). Au printemps, c'est assez simple, alors qu'en ejb, vous devez utiliser Arqullian avec ShrinkWrap (sic!) Qui est lent à exécuter sur chaque build.
- Persistance (ejb gagne). Au printemps, il y a des difficultés autour de lui, c'est-à-dire google "comment autowire la persistance dans l'écouteur d'entité" http://bit.ly/1P6u5WO
- Configuration (ejb gagne). En tant que débutant venant au printemps de ejb, j'ai été surpris par une multitude d'annotations et de fichiers .xml.
EJB 3.1 est le meilleur tout en étant la norme pour les applications Java 6 EE.
Spring ne prend toujours pas en charge Java 6 CDI (soudure) dépend également beaucoup de la configuration XML. EJB 3.1 est puissant et intelligent.
Je pense que Spring 3.1 n'a besoin d'aucune configuration XML. Vous avez la possibilité d'utiliser des annotations pour la configuration.