¿Se prefiere Spring + Hibernate en lugar de EJB 3?

Creo que cada vez que comienzan nuevos proyectos JEE (donde estas tecnologías serían aplicables), las personas prefieren usar una combinación de Spring + Hibernate en lugar de EJB 3.

Parece que incluso se recomienda a los programadores junior que lo hagan en lugar de EJB.

¿Es esta preferencia personal o hay razones pertinentes para ello? (por ejemplo, cicatrices personales creadas por versiones anteriores de EJB que causaron desconfianza en EJB o hinchazón tecnológica versus razones de rendimiento o curva de aprendizaje)?

Los frameworks EJB 3+ son bastante buenos, ya que vinieron junto con JPA como respuesta para los frameworks de persistencia configurados por anotaciones, así como CDI que permite la inyección de dependencias configurada por anotaciones. También agregas encima de esa soldadura. Spring, por otro lado, acaba de ponerse al día en el juego con la configuración a través de la anotación.

Dicho esto, no debe descartarse el retroceso histórico contra EJB1 y 2. No solo dejaron de resolver los problemas con la escritura de aplicaciones empresariales, fallaron espectacularmente . Fue un fracaso total por parte de los diseñadores tener un pulso sobre los verdaderos problemas que enfrentan los desarrolladores de aplicaciones web y empresariales y, a su vez, ofrecer las soluciones que realmente necesitaban.

Agregue además la desconfianza de que hay algunas sacudidas e inestabilidades serias con la dirección actual de Java en este momento y la falta de fe en los actuales administradores y propietarios de la antigua Sun JVM, en Oracle. Muchas personas no tienen fe en que Oracle mejorará a Java y liderará la dirección, y también existe el temor de que Apache Software Foundation pueda tirar la toalla. Cada vez más personas buscan OpenJDK para el futuro de Java, pero no es donde debe estar para la adopción empresarial.

Algunos ven todo esto como el olor de la muerte, ya que las aplicaciones empresariales son las principales razones por las que Java ha sido históricamente el lenguaje de programación número 1 en el mundo durante tanto tiempo. Es por eso que Microsoft ha estado ganando tanto terreno contra Java con las tecnologías .NET.

Los desarrolladores de aplicaciones Java no empresariales se están volcando cada vez más hacia OpenJDK y otros marcos de código abierto para ayudar a construir sus soluciones y algunos nunca miran hacia atrás. Se podría decir que es muy poco tiempo para que JEE vuelva a estar a la vanguardia de la legitimidad, aunque técnicamente JEE puede enfrentarse cara a cara con su aplicación Spring comparable.

EJB tiene mucho equipaje. Parte de ese equipaje proviene del hecho de que estaba dirigido al público equivocado. La otra parte fue que las dos primeras versiones eran una mierda.

Si observa las versiones originales de EJB, el diseño fue que un desarrollador de EJB podría crear una solución empaquetada que podría usarse dentro de cualquier contenedor compatible con EJB. Para una tienda interna, este nivel de abstracción era innecesario. Fue una solución perfecta para crear un mercado próspero para los proveedores de componentes EJB de terceros. Sin embargo, los vendedores de Contenedores eran demasiado entusiastas en su comercialización y estaban haciendo toneladas vendiendo su producto como una solución viable para el desarrollo diario. Esto sería el equivalente a construir todo el código de su aplicación como componentes COM +.

Para obtener más información sobre la especificación J2EE original, la mayoría de los proveedores involucrados tenían servidores CORBA y querían aprovechar esos productos en el futuro. La especificación EJB se creó sobre el protocolo IIOP (en realidad, Java RMI, que era una capa delgada sobre IIOP). CORBA ya había sido rechazado debido a su complejidad, y EJB era simplemente CORBA disfrazado, por lo que trajo consigo muchos de los problemas que tenía CORBA. En realidad, las abstracciones de EJB hicieron que fuera más difícil trabajar con lo que hubiera sido una implementación CORBA pura.

Una vez que el caucho golpeó el pavimento, la gente se dio cuenta de que el rendimiento con EJB era atroz. Como cada llamada es una llamada remota y la dificultad de incluso poner la aplicación en funcionamiento correctamente, la gente rápidamente buscó alternativas. Hibernate y Spring corriendo en un contenedor JSP se convirtieron en la solución.

EJB 3 "adoptó" este enfoque. Pero sigue siendo un compromiso genérico que no proporciona muchos beneficios. Todavía no hay un mercado de componentes EJB de terceros, por lo que realmente no tiene sentido usar un contenedor EJB para construir su solución.

Larga historia corta. Si bien EJB 3 es una gran mejora con respecto a las dos primeras iteraciones, todavía no proporciona suficientes beneficios para superar los costos.