Est-ce que Spring + Hibernate est préféré à EJB 3?

J'ai l'impression que chaque fois que de nouveaux projets JEE démarrent (là où ces technologies seraient applicables), les gens préfèrent utiliser une combinaison de Spring + Hibernate au lieu d'EJB 3.

Il semble que les programmeurs juniors soient même invités à opter pour cela au lieu d'EJB.

Est-ce une préférence personnelle ou y a-t-il des raisons pertinentes? (par exemple, des cicatrices personnelles créées par des versions d'EJB antérieures qui ont provoqué une méfiance à l'égard des EJB ou un ballonnement technologique par rapport à des raisons de performances ou à une courbe d'apprentissage)?

Les frameworks EJB 3+ sont en fait assez bons car ils sont venus avec JPA comme réponse aux frameworks de persistance configurés par annotation, ainsi que CDI qui permet l'injection de dépendances configurée par annotation. Vous ajoutez également au-dessus de cette soudure. Le printemps, en revanche, vient de rattraper son retard dans le jeu avec la configuration par l'annotation.

Cela étant dit, le backlack historique contre EJB1 et 2 ne doit pas être actualisé. Ils n'ont pas seulement échoué à résoudre les problèmes d'écriture d'applications d'entreprise, ils ont échoué de façon spectaculaire . Ce fut un échec complet de la part des concepteurs pour obtenir une impulsion sur les vrais problèmes auxquels sont confrontés les développeurs d'applications Web et d'entreprise et à leur tour fournir les solutions dont ils avaient réellement besoin.

Ajoutez à cela la méfiance qu'il y a de sérieux bouleversements et instabilités avec la direction actuelle de Java en ce moment et le manque de confiance dans les administrateurs et propriétaires actuels de l'ancienne Sun JVM, dans Oracle. Beaucoup de gens ne croient pas qu'Oracle améliorera Java et dirigera la direction et il y a aussi la crainte que la Apache Software Foundation ne jette l'éponge. De plus en plus de gens se tournent vers OpenJDK pour l'avenir de Java, mais ce n'est tout simplement pas là où il doit être pour l'adoption par l'entreprise.

Certains voient tout cela comme l'odeur de la mort, car les applications d'entreprise sont les principales raisons pour lesquelles Java a toujours été le langage de programmation n ° 1 dans le monde depuis aussi longtemps. C'est pourquoi Microsoft a gagné autant de terrain contre Java avec les technologies .NET.

Les développeurs d'applications Java non basés sur l'entreprise se tournent de plus en plus vers OpenJDK et d'autres frameworks open source pour aider à construire leurs solutions et certains ne regardent jamais en arrière. On pourrait dire que c'est trop peu trop tard pour remettre JEE à la pointe de la légitimité, même si techniquement, JEE peut et se tient aux pieds avec votre application Spring comparable.

EJB a beaucoup de bagages. Une partie de ce bagage vient du fait qu'il était destiné au mauvais public. L'autre partie était que les deux premières versions étaient complètement nulles.

Si vous regardez les versions originales d'EJB, la conception était qu'un développeur d'EJB pourrait créer une solution packagée qui pourrait être utilisée dans n'importe quel conteneur compatible EJB. Pour un magasin maison, ce niveau d'abstraction n'était pas nécessaire. C'était une solution parfaite pour créer un marché florissant pour les fournisseurs de composants EJB tiers. Cependant, les vendeurs de conteneurs étaient trop zélés dans leur marketing et faisaient des tonnes en vendant leur produit comme une solution viable pour le développement de tous les jours. Ce serait l'équivalent de la construction de tout votre code d'application en tant que composants COM +.

Pour plus d'informations sur la spécification J2EE d'origine, la plupart des fournisseurs impliqués disposaient de serveurs CORBA et souhaitaient tirer parti de ces produits à l'avenir. La spécification EJB a été construite sur le protocole IIOP (en fait Java RMI qui était une couche mince sur IIOP). CORBA avait déjà été rejeté en raison de sa complexité, et EJB n'était que CORBA déguisé, ce qui entraîna de nombreux problèmes avec CORBA. En fait, les abstractions d'EJB ont rendu plus difficile le travail avec une implémentation CORBA pure.

Une fois que le caoutchouc a frappé le trottoir, les gens ont réalisé que les performances avec EJB étaient atroces. Chaque appel étant un appel à distance et la difficulté même de démarrer l'application correctement pour commencer, les gens ont rapidement cherché des alternatives. Hibernate et Spring fonctionnant dans un conteneur JSP sont devenus la solution.

L'EJB 3 a "adopté" cette approche. Mais c'est toujours un compromis générique qui n'apporte pas beaucoup d'avantages. Il n'y a toujours pas de marché de composants EJB tiers, il est donc inutile d'utiliser un conteneur EJB pour créer votre solution.

Longue histoire courte. Alors que EJB 3 est une grande amélioration par rapport aux deux premières itérations, il ne fournit toujours pas assez d' avantages pour compense largement le coût.