Solución:
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 ocurre con JDO.)
- Hibernate se puede utilizar como una implementación de JPA.
- Sin embargo, Hibernate proporciona una API nativa, con características que van más allá de las de JPA.
En mi opinión, recomendaría Hibernate.
Ha habido algunos comentarios / preguntas sobre lo que debe hacer si necesitar para utilizar funciones específicas de Hibernate. Hay muchas formas de ver esto, pero mi consejo sería:
-
Si no le preocupa la posibilidad de vinculación con el proveedor, elija entre Hibernate y otras implementaciones de JPA y JDO incluso las diversas extensiones específicas del proveedor en su toma de decisiones.
-
Si le preocupa la posibilidad de vinculación con el proveedor y no puede usar JPA sin recurrir a extensiones específicas del proveedor, no use JPA. (Lo mismo ocurre con JDO).
En realidad, probablemente necesitará compensar cuánto le preocupa la vinculación del proveedor frente a cuánto necesita esas extensiones específicas del proveedor.
Y también hay otros factores, como qué tan bien usted o su personal conocen las tecnologías respectivas, cuánto costarán los productos en la concesión de licencias y la historia de quién 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 es 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 así’ que le quitó la diversión de modelar y codificar libremente como queramos. JDO tiene Nunca me hizo ajustar mi código o mi modelo para que “funcione correctamente”. Puedo diseñar y codificar POJO simples como si fuera a usarlos solo “en la memoria”, pero puedo conservarlos de forma 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 la memoria porque utiliza la mejora del código de bytes de tiempo de compilación (tal vez agregue 1 segundo a su tiempo de compilación para un proyecto grande) en su lugar que el patrón de proxy impulsado por reflexión en tiempo de ejecución de hibernate.
Otra cosa que puede resultarle molesta con Hibernate es que tiene una referencia 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, el patrón de proxy es necesario para permitir la carga bajo demanda (es decir, evitar la extracción de todo el gráfico de objetos cuando ingresa un objeto de nivel superior). Esté preparado para anular los valores iguales y el código hash porque el objeto al que cree que está haciendo referencia a menudo es solo un proxy para ese objeto.
Aquí hay un ejemplo de 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 codificar para ‘soluciones alternativas’, entonces, seguro, Hibernate es para usted. Si aprecia el desarrollo limpio, puro, orientado a objetos e impulsado por modelos, en el que dedica todo su tiempo a modelar, diseñar y codificar, y nada de eso a soluciones desagradables, dedique unas horas a evaluar JDO / DataNucleus. Las horas invertidas se amortizará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 la migración de proyectos JPA existentes de 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 en 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 tema a considerar al elegir un ORM es la eficiencia de su mecanismo de verificación sucia, 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 de HIBERNATE muy lenta
Recientemente he evaluado y elegido un marco 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 primariamente:
- 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 otra que no es SQL y viceversa.
- sin objetos proxy y, por lo tanto, menos dolor con respecto a las implementaciones de hashcode () y equals ()
- más POJO y, por lo tanto, se requieren menos soluciones
- admite más tipos de relaciones y campos
y el apoyo a favor de JPA es primariamente:
- más popular
- jdo está muerto
- no utiliza la mejora del código de bytes
Veo 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 veo 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 de RDBMS en lugar de ser técnicamente superior. (Me suena a VHS / Betamax).
JDO y su implementación de referencia Datanucleus claramente no está muerta, 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 aún no hay 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.
Acabo de comenzar a usar JDO / Datanucleus y lo tengo configurado para poder cambiar fácilmente entre el uso de db4o y mysql. Es útil para un desarrollo rápido usar db4o y no tener que preocuparse demasiado por el esquema de la base de datos y luego, una vez que el esquema está estabilizado, implementarlo en una base de datos. También estoy seguro de que, más adelante, podría implementar toda o 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 encontrar – 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. Preferiría tener un código más limpio, sin bloqueo de proveedor, más orientado a pojo, opciones nosql en lugar de 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 su propia decisión.