Hibernate vs JPA vs JDO: ¿pros y contras de cada uno? [cerrado]

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

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

Me está costando distinguir la diferencia entre la especificación JPA, lo que obtienes con la propia biblioteca 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?
• ¿Cuál sugerirías para un nuevo proyecto?
• ¿Hay ciertas condiciones en las que tendría sentido usar un marco frente al otro?

Algunas notas:

• JDO y JPA son especificaciones, no implementaciones.
• La idea es que puede intercambiar implementaciones de JPA, si restringe su código para usar solo JPA estándar. (Lo mismo para JDO.)
• Hibernate se puede utilizar como una implementación de JPA.
• Sin embargo, Hibernate proporciona una API nativa, con características superiores a las de JPA.

En mi opinión, recomendaría Hibernate.

Ha habido algunos comentarios / preguntas sobre lo que debe hacer si necesita usar funciones específicas de Hibernate. Hay muchas formas de ver esto, pero mi consejo sería:

• Si no le preocupa la perspectiva de un vínculo con el proveedor, elija Hibernate y otras implementaciones de JPA y JDO, incluidas las diversas extensiones específicas del proveedor en la toma de decisiones.

• Si le preocupa la posibilidad de un vínculo con el proveedor y no puede usar JPA sin recurrir a extensiones específicas del proveedor, entonces no use JPA. (Lo mismo para JDO).

En realidad, es probable que deba compensar cuánto le preocupa el vínculo del proveedor frente a cuánto necesita esas extensiones específicas del proveedor.

Y también hay otros factores, como qué tan bien usted / su personal conoce las tecnologías respectivas, cuánto costarán los productos en las licencias y qué historia cree sobre lo que sucederá en el futuro para JDO y JPA.

Asegúrese de evaluar la implementación de DataNucleus de JDO. Comenzamos con Hibernate porque parecía ser muy popular, pero pronto nos dimos cuenta de que no era 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 eliminó la diversión de modelar y codificar libremente como queramos. JDO tiene nunca me hecho 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 persistirlos de manera transparente.

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

Otra cosa que puede resultar molesta con Hibernate es que una referencia que tiene a lo que cree 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 a pedido (es decir, evitar tirar de 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 solo 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 te gusta la codificación para 'soluciones', entonces, seguro, Hibernate es para ti. Si aprecia el desarrollo limpio, puro, orientado a objetos e impulsado por modelos, en el que pasa todo su tiempo modelando, diseñando y codificando, y nada de eso en soluciones desagradables, luego pase unas horas evaluando JDO / DataNucleus . Las horas invertidas se pagarán mil veces.

Actualización de febrero de 2017

Desde hace bastante tiempo, DataNucleus implementa el estándar de persistencia JPA además del estándar de persistencia JDO, por lo que portar proyectos JPA existentes desde Hibernate a DataNucleus debería ser muy sencillo y puede obtener todos los beneficios mencionados anteriormente de DataNucleus con muy poco cambio 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 a JPA solamente.

Rendimiento de las actualizaciones de Hibernate DB

Otro tema a considerar al elegir un ORM es la eficiencia de su mecanismo de verificación sucio, que se vuelve muy importante cuando 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 verificación sucio de Hibernate en esta respuesta SO: JPA con inserción HIBERNATE muy lenta

Recientemente he evaluado y elegido un marco de persistencia para un proyecto de Java y mis hallazgos son los siguientes:

Lo que estoy viendo es que el apoyo a favor de JDO es principalmente:

• puede usar fuentes de datos que no sean SQL, db4o, hbase, ldap, bigtable, couchdb (complementos para cassandra), etc.
• puede cambiar fácilmente de una fuente de datos sql a no sql y viceversa.
• sin objetos proxy y, por lo tanto, menos dolor con respecto a las implementaciones de hashcode () y equals ()
• Se necesita más POJO y, por lo tanto, menos soluciones alternativas
• admite más relaciones y tipos de campo

y el apoyo a favor de JPA es principalmente:

• más popular
• jdo está muerto
• no utiliza la mejora de bytecode

Estoy viendo muchas publicaciones pro-JPA de desarrolladores de JPA que claramente no han usado JDO / Datanucleus que ofrecen argumentos débiles para no usar JDO.

También estoy viendo muchas publicaciones de usuarios de JDO que han migrado a JDO y como resultado están mucho más felices.

Con respecto a que JPA es más popular, parece que esto se debe en parte al soporte del proveedor RDBMS en lugar de ser técnicamente superior. (A mí me suena como VHS / Betamax).

JDO y su implementación de referencia Datanucleus claramente no está muerto, como lo demuestra la adopción de Google para GAE y el desarrollo activo en el código fuente (http://sourceforge.net/projects/datanucleus/).

He visto una serie de quejas sobre JDO debido a la mejora del código de bytes, pero todavía no hay una explicación de por qué es malo.

De hecho, en un mundo cada vez más obsesionado por las soluciones NoSQL, JDO (y la implementación del núcleo de datos) parece una apuesta mucho más segura.

Recién comencé a usar JDO / Datanucleus y lo configuré para poder cambiar fácilmente entre usar db4o y mysql. Es útil para el desarrollo rápido usar db4o y no tener que preocuparse demasiado por el esquema de base de datos y luego, una vez que el esquema se estabilice para implementarse en una base de datos. También me siento seguro de que más adelante, podría implementar toda / parte de mi aplicación en GAE o aprovechar el almacenamiento distribuido / reducir el mapa a la hbase / hadoop / cassandra sin demasiada refactorización.

Encontré el obstáculo inicial de comenzar con Datanucleus un poco complicado: la documentación en el sitio web de datanucleus es un poco difícil de abordar; los tutoriales no son tan fáciles de seguir como me hubiera gustado. Dicho esto, la documentación más detallada sobre la API y el mapeo es muy buena una vez que pasa la curva de aprendizaje inicial.

La respuesta es, depende de lo que quieras. Prefiero tener un código más limpio, sin bloqueo del proveedor, más orientado a pojo, las opciones nosql y los versos más populares.

Si desea la sensación cálida y quisquillosa de que está haciendo lo mismo que la mayoría de los otros desarrolladores / ovejas, elija JPA / hibernate. Si desea liderar en su campo, pruebe JDO / Datanucleus y tome una decisión.

¿Cuál sugerirías para un nuevo proyecto?

Yo sugeriría tampoco! Use Spring DAO's JdbcTemplatejunto con StoredProcedure, RowMappery en su RowCallbackHandlerlugar.

Mi propia experiencia personal con Hibernate es que el tiempo ahorrado por adelantado está más que compensado por los interminables días que pasará en el futuro 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é su código, más control tendrá. La capa DAO de Spring permite un control preciso de la capa de mapeo, al tiempo que elimina la necesidad de código repetitivo. Además, se integra en la capa de transacciones de Spring, lo que significa que puede agregar 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).

JDO está muerto

JDO no está muerto en realidad, así que por favor verifique sus hechos. JDO 2.2 fue lanzado en octubre de 2008 JDO 2.3 está en desarrollo.

Esto se desarrolla abiertamente, bajo Apache. Más lanzamientos que JPA ha tenido, y su especificación ORM aún está por delante de incluso las características propuestas por JPA2

JDO tiene características avanzadas que JPA, consulte http://db.apache.org/jdo/jdo_v_jpa.html

Estoy usando JPA (implementación de OpenJPA de Apache que se basa en la base de código KODO JDO que tiene más de 5 años y es extremadamente rápida / confiable). En mi humilde opinión, cualquiera que le diga que omita las especificaciones le está dando malos consejos. Puse el tiempo y definitivamente fui recompensado. Con JDO o JPA puede cambiar de proveedor con cambios mínimos (JPA tiene mapeo de ormas, por lo que estamos hablando de menos de un día para cambiar de proveedor). Si tienes más de 100 mesas como yo, esto es enorme. Además, obtienes caché integrado con desalojos de caché en clúster y todo está bien. SQL / Jdbc está bien para consultas de alto rendimiento, pero la persistencia transparente es muy superior para escribir sus algoritmos y rutinas de entrada de datos. Solo tengo alrededor de 16 consultas SQL en todo mi sistema (50k + líneas de código).

He estado investigando esto yo mismo y no puedo encontrar una gran diferencia entre los dos. Creo que la gran opción es en qué implementación utilizas. Para mí, he estado considerando la plataforma DataNucleus , ya que es una implementación independiente de ambos para el almacenamiento de datos.

Cualquiera que diga que JDO está muerto es un traficante de FUD astroturfing y 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 a JPA y usar 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 de modelado que trae JDO.

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

Luego cambiamos a Hibernate. Jugamos un poco con solo usar 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 comportamiento de almacenamiento en caché extraño a veces. Hay algunas construcciones DDL que Hibernate no puede manejar y, por lo tanto, se definen en un archivo adicional que se ejecuta para inicializar la base de datos. Cuando me encuentro 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 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. Hay muchas bases de datos Java en memoria que se pueden usar para realizar pruebas, pero generalmente son inútiles para la producción. Ser capaz de usar una base de datos real, pero limitada, aumentará la productividad del desarrollo y la confiabilidad del código.

Hice una WebApp de muestra en mayo de 2012 que usa JDO 3.0 y DataNucleus 3.0. Observe lo limpia que está: https://github.com/TorbenVesterager/BadAssWebApp

De acuerdo, tal vez sea un poco demasiado limpio, porque uso los POJO tanto para la base de datos como para el cliente JSON, pero es divertido :)

PD: contiene algunas anotaciones SuppressWarnings (desarrollado en IntelliJ 11)