[java] Hibernate vs JPA vs JDO - pros y contras de cada uno?



Answers

Asegúrese de evaluar la implementación de DataNucleus de JDO. Comenzamos con Hibernate porque parecía ser tan popular, pero pronto nos dimos cuenta de que no se trataba de una solución de persistencia 100% transparente. Hay demasiadas advertencias y la documentación está llena de "si tiene esta situación, entonces debe escribir su código de esta manera" que le quitó la diversión de modelar y codificar libremente como queramos. JDO nunca me ha obligado a ajustar mi código o mi modelo para que 'funcione correctamente'. Solo puedo diseñar y codificar POJO simples como si fuera a usarlos 'solo en memoria', pero puedo persistir de forma transparente.

La otra ventaja de JDO / DataNucleus sobre hibernación es que no tiene toda la sobrecarga de reflexión de tiempo de ejecución y es más eficiente en cuanto a memoria porque usa mejora de código de bytes de tiempo de compilación (quizás agregue 1 segundo a su tiempo de compilación para un proyecto grande) que el patrón de proxy alimentado por la reflexión del tiempo de ejecución de hibernate.

Otra cosa que puede resultar molesto con Hibernate es que se trata de una referencia de lo que crees que es el objeto ... a menudo es un "proxy" para el objeto. Sin el beneficio de la mejora del código de bytes, se requiere el patrón proxy para permitir la carga bajo demanda (es decir, evitar tirar todo el gráfico de objetos cuando se tira de un objeto de nivel superior). Esté preparado para anular equals y hashcode porque el objeto que cree que está haciendo referencia a menudo es simplemente un proxy para ese objeto.

Aquí hay un ejemplo de las frustraciones que obtendrá con Hibernate que no obtendrá con JDO:

http://blog.andrewbeacock.com/2008/08/how-to-implement-hibernate-safe-equals.html
http://burtbeckwith.com/blog/?p=53

Si le gusta la codificación de 'soluciones', entonces, seguro, Hibernate es para usted. Si aprecia el desarrollo limpio, puro, orientado a objetos y basado en modelos, donde pasa todo su tiempo modelando, diseñando y codificando, y nada de eso en soluciones desagradables, pase unas horas evaluando DataNucleus . Las horas invertidas se pagarán mil veces.

Actualización feb 2017

Desde hace bastante tiempo, DataNucleus implementa el estándar de persistencia JPA además del estándar de persistencia JDO, por lo que trasladar proyectos JPA existentes desde Hibernate a DataNucleus debería ser muy sencillo y puede obtener todos los beneficios de DataNucleus mencionados anteriormente con muy pocos cambios de código , Si alguna. Entonces, en términos de la pregunta, la elección de un estándar particular, JPA (solo RDBMS) vs JDO (RDBMS + No SQL + ODBMSes + otros), DataNucleus admite ambos, Hibernate está restringido solo a JPA.

Rendimiento de las actualizaciones de Hibernate DB

Otro aspecto a considerar cuando se elige un ORM es la eficiencia de su mecanismo de control sucio, que se vuelve muy importante cuando se necesita construir el SQL para actualizar los objetos que han cambiado en la transacción actual, especialmente cuando hay muchos objetos. Hay una descripción técnica detallada del mecanismo de control sucio de Hibernate en esta respuesta SO: JPA con inserto HIBERNATE muy lento

Question

Estoy familiarizado con ORM como concepto, e incluso he usado nHibernate hace varios años para un proyecto .NET; sin embargo, no he seguido el tema de ORM en Java y no he tenido la oportunidad de utilizar ninguna de estas herramientas.

Pero, ahora puedo tener la oportunidad de comenzar a utilizar algunas herramientas ORM para una de nuestras aplicaciones, en un intento de alejarme de una serie de servicios web heredados.

Me está costando diferenciar la diferencia entre las especificaciones de JPA, lo que obtienes con la biblioteca de Hibernate y lo que JDO tiene para ofrecer.

Entonces, entiendo que esta pregunta es un poco abierta, pero esperaba obtener algunas opiniones sobre:

  • ¿Cuáles son los pros y los contras de cada uno?
  • ¿Qué recomendarías para un nuevo proyecto?
  • ¿Hay ciertas condiciones en las que tendría sentido usar un marco frente al otro?






He utilizado Hibernate (implementación de JPA) y JPOX (implementación de JDO) en el mismo proyecto. JPOX funcionó bien, pero se topó con errores bastante rápido, donde algunas características del lenguaje Java 5 no eran compatibles en ese momento. Tenía problemas para jugar bien con las transacciones XA. Estaba generando el esquema de la base de datos desde los objetos JDO. Quería conectarse a una base de datos cada vez, lo que es molesto si su conexión Oracle no funciona.

Luego cambiamos a Hibernate. Estuvimos jugando solo con JPA puro por un tiempo, pero necesitábamos usar algunas de las características específicas de Hibernate para hacer el mapeo. Ejecutar el mismo código en múltiples bases de datos es muy fácil. Hibernate parece almacenar en caché los objetos agresivamente o simplemente tiene un extraño comportamiento de almacenamiento en caché a veces. Hay algunas construcciones DDL que Hibernate no puede manejar, por lo que se definen en un archivo adicional que se ejecuta para inicializar la base de datos. Cuando me he encontrado con un problema de Hibernate, a menudo hay muchas personas que se han encontrado con el mismo problema, lo que facilita la búsqueda de soluciones en Google. Finalmente, Hibernate parece estar bien diseñado y confiable.

Algunos otros respondedores han sugerido simplemente usar SQL. El caso de uso real asesino para el mapeo relacional de objetos es la prueba y el desarrollo. Las bases de datos que se crean para manejar grandes volúmenes de datos suelen ser costosas o difíciles de instalar. Son difíciles de probar con. Hay muchas bases de datos Java en la memoria que se pueden usar para probar, pero generalmente son inútiles para la producción. Poder usar una base de datos real, pero limitada, aumentará la productividad de desarrollo y la confiabilidad del código.




Cualquiera que diga que JDO está muerto es un traficante de FUD astroturfing y ellos lo saben.

JDO está vivo y bien. La especificación es aún más poderosa, madura y avanzada que la JPA mucho más joven y limitada.

Si desea limitarse solo a lo que está disponible en el estándar JPA, puede escribir en JPA y utilizar DataNucleus como una implementación de persistencia más transparente y de alto rendimiento que las otras implementaciones de JPA. Por supuesto, DataNucleus también implementa el estándar JDO si desea la flexibilidad y eficiencia del modelado que aporta JDO.




¿Qué recomendarías para un nuevo proyecto?

Yo sugeriría ninguno! En su lugar, utilice la JdbcTemplate Spring DAO junto con RowMapper , RowMapper y RowCallbackHandler .

Mi propia experiencia personal con Hibernate es que el tiempo ahorrado desde el principio queda más que compensado por los días interminables que pasará en la línea tratando de comprender y depurar problemas como el comportamiento inesperado de la actualización en cascada.

Si está utilizando una base de datos relacional, cuanto más cerca esté de su código, más control tendrá. La capa DAO de Spring permite un control fino de la capa de mapeo, al tiempo que elimina la necesidad de un código repetitivo. Además, se integra en la capa de transacciones de Spring, lo que significa que puede agregar muy fácilmente (a través de AOP) un comportamiento transaccional complicado sin que esto se entrometa en su código (por supuesto, también lo obtiene con Hibernate).




Related