2011-01-09 11 views
11

En cuanto a una aplicación web Java EE que va a ser servida por un servidor de aplicaciones Java EE completo, p. GlassFish, ¿cuál es la mejor solución ORM? EJB 3 o Hibernate 3 ¿Y por qué?EJB 3 o Hibernate 3

+1

Existen muchas otras soluciones de persistencia que tienen distintas ventajas; parece que los has ignorado en tu pregunta, por lo que cualquier respuesta de lo que es "lo mejor" es arbitraria. Probablemente, lo mejor depende de la aplicación en sí, de los desarrolladores que lo están escribiendo y del almacén de datos que se usa ... y no ha proporcionado información sobre esos – DataNucleus

Respuesta

27

Esos dos son completamente diferentes.

EJB3 es un modelo de componente y no tiene nada que ver directamente con ORM. Ayuda con la administración de transacciones de manera fácil y le brinda acceso fácil al administrador de entidades desde JPA, que es una solución ORM estandarizada en Java EE.

Hibernate (3) es de hecho una solución ORM, y como ocurre una que implementa JPA.

Así que una pregunta más lógica es si usar las interfaces JPA estandarizadas, o usar la API central de Hibernate directamente. Entonces una pregunta de seguimiento podría ser si usar JPA de forma independiente, o en combinación con EJB 3.

La respuesta depende un poco de lo que necesita exactamente, pero generalmente el uso de JPA en combinación con EJB 3 es la solución más fácil. El uso de JPA o Hibernate autónomo requiere un código mucho más detallado y usted tiene que gestionar manualmente las transacciones, lo que puede ser un problema.

JPA vs Hibernate es otro debate. JPA tiene el beneficio de tener las interfaces estandarizadas, por lo que es probable que más desarrolladores estén familiarizados con él. Por otro lado, las API nativas de Hibernate son siempre un conjunto excelente de las de JPA y, por lo tanto, ofrecen más potencia.

Normalmente, los desarrolladores basan su código principalmente en JPA, y luego usan algunas anotaciones específicas de Hibernate o llamadas API donde tiene sentido. En el 99.99% de los casos, se admite el uso mixto de API.

También tenga en cuenta que Glassfish se incluye con EclipseLink, no con Hibernate. EclipseLink es comparable con Hibernate pero es anterior a más de una década. Hibernate tomó mucho de EclipseLink (llamado TopLink en aquel entonces).

Véase también esta respuesta que he dado a una pregunta similar: Database table access via JPA Vs. EJB in a Web-Application

-1

Son similares; la especificación 3.0 para EJB tomó mucho de Hibernate y Spring.

No tengo ninguna métrica firme para cualquiera de las dos, pero diría que si usted está adoptando Glassfish, tiene sentido para mí usar toda su tecnología. ¿Por qué introducir otra dependencia? Vea si Glassfish puede hacer el trabajo por usted.

5

Lo que se plantea es qué API es mejor: EJB3 (APP) o hibernación? Lo dije porque preguntas sobre EJB3 JPA (que es solo API) e Hibernate (que es implementación y API). Por lo tanto, para comparar manzanas con manzanas, debe comparar las API. Puede elegir entre la API estándar (JPA) y la API propietaria más poderosa (Hibernate).

Pero al elegir JPA hay otra opción que hacer: para su implementación. Al elegir Hibernate para su implementación, básicamente puede descartar su pregunta, ya que tanto JPA como Hibernate están disponibles.

Entonces su pregunta cambiaría: ¿qué implementación de JPA debería elegir (entre Hibernate, EclipseLink, OpenJPA, DataNucleus, etc.)? ...

+0

Tenga en cuenta que * EJB3 (JPA) * podría ser un poco confuso. Sugiere que EJB3 es otro nombre para JPA, pero este no es el caso. Ya era técnicamente una especificación completamente separada en EJB 3.0, y esto se ha formalizado en la versión 3.1 actual de EJB. JPA no es tanto técnica como organizacional una especificación completamente diferente. No puedes intercambiar los términos de ninguna manera. –

+0

Todo lo que quise decir es seguir la terminología en las preguntas de Ehsun. Gracias por las aclaraciones. – topchef

Cuestiones relacionadas