mejores características de EJB 3

Question

El escenario

• Se han desarrollado una aplicación web utilizando EJB versión 3.
• El sistema se despliega, entregado y es utilizado por el cliente.

Si tuviera que volver a escribir el sistema desde cero, ¿volvería a utilizar los EJB?

No: No conteste esta pregunta, responda this one en su lugar.

Sí: Proporcionan un problema importante y real que los EJB resuelven, de acuerdo con su experiencia personal.

Deja que la respuesta contenga solo un problema. Esto permitirá que otros lectores voten por la mejor característica de los EJB.

Answer 1

Bueno, esto realmente depende de qué EJB estamos hablando. Diría que los MDB aún pueden ser útiles incluso ahora. Para beans de entidad y beans de sesión seguramente puede encontrar un mejor enfoque. Tal vez una característica que todavía me gusta en EJB es la escalabilidad. Usando la opción "remota" puede implementar EJB en diferentes servidores si es necesario. Sin embargo, no creo que esto sea realmente necesario, y solo he visto un gran proyecto en el que fue realmente útil.

Answer 2

Creo que depende de qué versión de EJB estás hablando. Discutamos las únicas dos versiones relevantes (IMO).

EJB 2.1 aún puede ser utilizado por algunas personas en un sistema heredado. Realmente tienen el mayor uso como abstracción RPC. También proporcionaron un sistema rudimentario ORM (Object Relational Mapping) también. Y como mencionó, se proporciona soporte de transacciones. Entonces, si estuviera construyendo un sistema en el que quisiera comunicarse con un sistema remoto, transfiera datos orientados a objetos y lo haga de forma transaccional, puede encontrar que los EJB valen la pena. De lo contrario, yo diría que se mantenga alejado.

EJB 3.0, sin embargo, se ha mejorado mucho. Tiene todas las características de la versión anterior, pero lo hace de una manera más directa. También proporciona un marco de Inversión de control bastante simple, similar a Spring, y un ORM bastante decente en forma de JPA (Java Persistence API). He utilizado EJB 3.0 y en realidad lo disfruté. Podría argumentar a favor del uso de EJB 3.0 de la misma manera que lo haría para Spring, además de que tiene algunas características más avanzadas o de enterprise-y disponibles.

Answer 3

Hice mucho trabajo en el pasado con EJB 2.1, me alegro de dejarlo atrás.

La propuesta de valor de EJB sigue siendo cierta para 3.0, y tiene un buen modelo de programación ligera. La gestión de transacciones, la concurrencia, el control de versiones de datos, la gestión del estado, estos son problemas no triviales para resolver correctamente y los marcos de Java EE continúan haciendo un excelente trabajo.

Es cierto que utilizo Hibernate y Seam para seguir desarrollando algunas de las características de Java EE, por lo que no es estrictamente justo para mí decir que EJB 3.0 es la meca. Sin embargo, hay demasiados desarrolladores que arrojan al proverbial bebé con el agua de la bañera cuando abandonan por completo a Java y pasan a algo más moderno como Rails.

Seam proporciona un buen marco de pegamento que mantiene la cantidad de esfuerzo del programador bastante baja. También le permite decidir proyecto por proyecto cuando EJB tiene sentido versus POJOs, SIN tener que cambiar su estilo de programación.

Answer 4

Una cosa que ha mordido a muchos al usar EJB, o J2EE en general, es la dependencia del servidor de aplicaciones en el que está ejecutando sus EJB. El servidor de aplicaciones tiende a ser compatible con un conjunto particular de versiones de sistemas operativos y versiones de JVM. No tener el código fuente en una parte importante de su entorno de tiempo de ejecución también podría convertirse en un desafío.

Si bien en principio es posible la migración de un proveedor a otro, debe tener muy en cuenta las pequeñas diferencias en la forma en que implementan la especificación, y mantenerse alejado de las extensiones específicas del proveedor.

Dicho esto, los servidores de aplicaciones a los que he estado expuesto pueden manejar mucho el abuso del código que se ejecuta en él y funcionan muy bien.

Answer 5

Convención sobre la configuración.

El comportamiento predeterminado de EJB 3 es más a menudo el deseado. Creo que el principal problema con EJB 2.1 fue la necesidad de los archivos de configuración detallados, la nueva configuración basada en anotaciones resuelve la mayor parte de este problema.

Answer 6

la razón principal para usar la plataforma java ee es por definición. necesita una plataforma que resuelva los problemas de concurrencia, disponibilidad, gestión de transacciones, mensajería y administración en una plataforma totalmente comprobada, compatible y compatible. sí, puede hacerlo todo usted mismo combinando una gran cantidad de bibliotecas y colocándolas encima de tomcat, pero ¿por qué desperdiciar todo ese tiempo examinando y administrando la compatibilidad y el conjunto de características cuando puede escribir en una plataforma que hace cumplir las normas y que es totalmente revisada? cualquier contenedor ee DEBE pasar el tck o no puede transportar el monicker Java EE.

las cosas que varias personas plantean sobre "peso ligero", "tipos" de ejbs, etc. son superfluas. si no necesita el conjunto de características de la plataforma o la garantía de la compatibilidad intra completa de sus bibliotecas apalancadas, entonces ejb (también conocido como la plataforma java ee) es excesivo. pero si realmente está resolviendo un problema de calidad empresarial (consulte el primer párrafo), entonces el ejb y la plataforma java ee le brindarán lo que necesita.