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

Asegúrese de evaluar la implementación de DataNucleus de JDO. Empezamos con Hibernate porque parecía ser muy popular, pero muy pronto nos dimos cuenta de que no es una solución de persistencia 100% transparente. Hay demasiadas advertencias y la documentación está llena de 'si tienes esta situación, entonces debes escribir tu código de esta manera' que nos quitó la diversión de modelar y codificar libremente como queramos. JDO ha nunca me ha hecho ajustar mi código o mi modelo para que funcione correctamente. Solo puedo diseñar y codificar POJOs simples como si fuera a usarlos 'en memoria' solamente, sin embargo, puedo persistirlos de manera transparente.

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

Otra cosa que puede encontrar molesto con Hibernate es que una referencia a lo que usted piensa 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 de todo el gráfico de objetos cuando se tira de un objeto de nivel superior). Prepárese 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 frustraciones que obtendrás con Hibernate que no obtendrás con JDO:

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

Si te gusta codificar a 'workarounds' entonces, claro, Hibernate es para ti. Si aprecia el desarrollo limpio, puro, orientado a objetos y basado en modelos, donde dedica todo su tiempo a modelar, diseñar y codificar, y nada de eso en soluciones feas, pase unas horas evaluando JDO/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 portar proyectos JPA existentes de Hibernación 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 lo hay. Así que 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, Hibernación está restringido solo a JPA.

Rendimiento de las actualizaciones de la base de datos de Hibernación

Otro problema a considerar al elegir un OR es la eficiencia de su mecanismo de dirty checking - 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 un descripción técnica detallada del mecanismo de verificación sucio de Hibernate en esta respuesta SO: JPA con inserción de HIBERNACIÓN muy lenta

Recientemente he evaluado y seleccionado un framework de persistencia para un proyecto 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 no sql, db4o, hbase, ldap, bigtable, couchdb (complementos para cassandra), etc.
• puede cambiar fácilmente de una fuente de datos sql a otra no sql y viceversa.
• no hay objetos proxy y por lo tanto menos dolor con respecto a hashcode () e igual() implementaciones
• más POJO y por lo tanto menos soluciones requeridas
• soporta más tipos de relaciones y campos

Y el apoyo a JPA es principalmente:

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

Estoy viendo muchos posts pro-JPA de desarrolladores de JPA que claramente no han usado JDO/Datanucleus ofreciendo argumentos débiles para no usar JDO.

También estoy viendo un montón de mensajes de Usuarios de JDO que han migrado a JDO y son mucho más felices como resultado.

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. (Suena como VHS / Betamax para mí).

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

He visto un número de quejas sobre JDO debido a la mejora de bytecode, pero aún no hay explicación de por qué es malo.

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

Acabo de empezar a usar JDO/Datanucleus y lo tengo configurado para que pueda cambiar fácilmente entre el uso de db4o y mysql. Es útil para el desarrollo rápido utilizar db4o y no tener que preocuparse demasiado por el esquema de base de datos y luego, una vez que el esquema se estabiliza para desplegar en una base de datos. También estoy seguro de que más adelante, podría implementar toda / parte de mi aplicación en GAE o aprovechar el almacenamiento distribuido/map-reduce 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 entrar - los tutoriales no son tan fáciles de seguir como me hubiera gustado. Habiendo dicho eso, la documentación más detallada en la API y la asignación es muy buena una vez que se pasa la curva de aprendizaje inicial.

La respuesta es, depende de lo que quieras. Preferiría tener un código más limpio, sin bloqueo de proveedor, más orientado a pojo, opciones nosql más populares.

Si quieres la cálida sensación quisquillosa de que estás haciendo lo mismo que la mayoría de otros desarrolladores/sheep, elige JPA/hibernate. Si desea liderar en su campo, pruebe JDO / Datanucleus y haga su mente propia.

¿Qué sugerirías para un nuevo proyecto?

Yo sugeriría tampoco! Utilice Spring DAO JdbcTemplate junto con StoredProcedure, RowMapper y RowCallbackHandler en su lugar.

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

Si está utilizando una BD relacional, cuanto más cerca esté su código de ella, más tienes el control. 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 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 se obtiene esto con Hibernate).

JDO está muerto

JDO no está muerto en realidad, así que por favor revise 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 versiones de las que JPA ha tenido, y su especificación OR aún está por delante incluso de las características propuestas por JPA2

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

Estoy usando JPA (implementación OpenJPA de Apache que se basa en la base de código JDO de KODO que tiene más de 5 años y es extremadamente rápida/confiable). En mi humilde opinión, cualquiera que te diga que evites las especificaciones te está dando malos consejos. Puse el tiempo en y fue definitivamente recompensado. Con JDO o JPA puede cambiar los vendedores con cambios mínimos (JPA tiene mapeo orm así que estamos hablando de menos de un día, posiblemente, el cambio de proveedores). Si tienes más de 100 mesas como yo, esto es enorme. Además obtienes almacenamiento en caché built0in 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 (más de 50k líneas de código).

Cualquiera que diga que JDO está muerto es un astroturfing FUD monger y lo saben.

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

Si desea limitarse solo a lo que está disponible en el estándar JPA, puede escribir en JPA y usar DataNucleus como una implementación de persistencia de alto rendimiento y más transparente 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 aporta JDO.

He estado buscando en esto yo mismo y no puedo encontrar una fuerte diferencia entre los dos. Creo que la gran elección es en qué implementación se utiliza. Para mí, he estado considerando la plataforma DataNucleus , ya que es una implementación agnóstica de ambos almacenes de datos.

He utilizado Hibernate (implementación de JPA) y JPOX (implementación de 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 base de datos a partir de los objetos JDO. Quería conectarse a una base de datos cada vez que es molesto si su conexión de Oracle sucede no está funcionando.

Luego cambiamos a Hibernar. Nos jugamos con solo usar JPA puro por un tiempo, pero necesitábamos usar algunas de las características específicas de Hibernación para hacer el mapeo. Ejecutar el mismo código en varias bases de datos es muy fácil. Hibernate parece almacenar objetos en caché de forma agresiva o simplemente tener 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 he topado con un problema de hibernación a menudo hay muchas personas que se han encontrado con el mismo problema que hace que buscar soluciones en Google sea más fácil. Finalmente, Hibernate parece estar bien diseñado y confiable.

Algunos otros respondedores han sugerido simplemente usar SQL. El verdadero caso de uso 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 caras o difíciles de instalar. Son difíciles de probar. Hay un montón de bases de datos Java en memoria que pueden ser se utiliza para probar con, pero son típicamente inútiles para la producción. Ser capaz de utilizar una base de datos real, pero limitada, aumentará la productividad del desarrollo y la fiabilidad del código.

Hice una aplicación web de muestra en mayo de 2012 que utiliza JDO 3.0 y DataNucleus 3.0-echa un vistazo a lo limpio que está: https://github.com/TorbenVesterager/BadAssWebApp

Está bien tal vez es un poco demasiado limpio, porque uso los POJOs tanto para la base de datos como para el cliente JSON, pero es divertido :)

PS: Contiene algunas anotaciones de SuppressWarnings (desarrollado en IntelliJ 11)