Tres personas me han preguntado últimamente porque ORM (Object-Relational Mapping) escoger para sus proyectos Java. A los tres les he contestado lo mismo, así que por si sirve de algo a alguien, dejaré aquí la respuesta.
Siendo honestos (en términos de uso, perspectiva de futuro, etc.) las opciones son pocas en este caso, al menos a día de hoy. Básicamente dos:
- Hibernate
- JDO 2.0
Hibernate es sin duda el rey. El más usado, existe muchísima documentación, probado y más que probado, etc. Lo que quieras. Sin embargo mi recomendación es para JDO 2, por estas tres razones básicamente:
- Estándar: quieras que no, Hibernate sólo hay uno, implementaciones de JDO, no. Puedes pasar de una a otra (incluso libres) sin grandes problemas.
- Sencillez: opinión personal, pero JDO 2.0 es mucho más sencillo. Quieras que no es más moderno, se ha aprendido de errores, incluso Gavin King (el creador de Hibernate) ha puesto su granito de arena para que esto sea así. Te puede gustar más o menos la forma, pero es más sencilla.
- Futuro: el API de JDO 2.0 es casi exacto al API de EJB 3 (para los despistados: olvidar todo lo que sabéis de EJBs), aprender JDO 2.0 es aprender EJB 3.0. De hecho, el propio Hibernate va a soportar este API en futuras versiones.
Esas son mis razones a favor de JDO. En contra… sólo una…. la escasez de documentación. Es suficiente para hacer de todo (relaciones, attach/detach complejos, queries de todo tipo, cachés, etc), pero debido a su juventud la cantidad de artículos es bastante más reducida.
¿Comentarios?.
Pocos comentarios te puedo hacer por que solo he utilizado Hibernate. Pero tengo una pregunta… ¿qué implementación de JDO aconsejarías? Me gustaría probar alguna, cual crees que está más madura/ da menos problemas?
Gracias
Hombre, de las libres la mejor es JPOX (http://www.jpox.org), no le he encontrado demasiados problemas, no más de los habituales.
Tiene una paradoja: tiene mucha documentación y buena, pero mal organizada (aunque al principio no lo parece) y a veces cuesta encontrar lo que estás buscando.
Suerte.
En mi caso usé EJB2.x para la capa de persistencia de una RIA bastante grande (hecha con Flash/OpenAMF/JOnAS).
En un principio pensé que era un gran avance con respecto a usar DAOs, y sigo creyendolo, pero lo cierto es que hay muchos problemas asociados.
Parece ser que gran parte de estos problemas se resuelven con EJB3, por eso estoy mirando atentamente “EasyBeans” de ObjectWeb. De momento no puedo decir mucho, las pruebas que hice me gustaron bastante, pero hay que tener en cuenta que el proyecto está todavía en desarrollo, aunque mu y avanzado (la última versión es la 1.0M1).
psss…. ya sabes con que me quedo yo, licurgo!!
Este verano espero desarrollar un poco mas alguna funcionalidad que tengo pendiente, pero dos años despues sigue “funcionandonos”
Hola Enrique, nice to see you
.
No he dicho que Licurgo no sea una opción, pero si me tendrás que reconocer que sus perspectivas de llegar al gran público son mínimas mientras no se le dedique tiempo al marketing.
En todo caso, sobre funcionalidad, dos ideas, por si te sirven (si quieres lo discutimos en la lista, aún estoy, creo):
- que DbObject implemente “java.util.Map”. Eso hará que los objetos puedan ser llamados por el patrón “bean” (el de objeto.campo) que siguen la mayoría de herramientas y frameworks. Ahora sólo funciona en Fremarker y alguna cosa más.
- posibilidad de definir “campos de consultas” en el XML del objeto. Ummm… que pueda definir el campo “clientes” y que su descripción sea un SQL (o dialecto de SQL) que haga la carga. No sé si me he explicado, sería algo así como:
[object …]
…
[field name=”clientes”]select * from clientes where x=y[/field]
[/object]
dónde cliente debería estar definido como objeto de licurgo también. Esto es un poco “al estilo rails”.
Estoy de acuerdo contigo, me quedo con JDO sin dudarlo, y he tenido que pegarme con los dos desde hace mucho tiempo.
Pero quiero recalcar una detalle. Dices:
“El más usado, existe muchísima documentación, probado y más que probado, etc.”
En esto no estoy deacuerdo. Es verdad que google está lleno de ejemplos de gente que usa hibernate, de foros donde la gente pregunta y otros que dicen saber contestan, etc… Pero la documentación de verdad, es muy mala.
Además, las aportaciones en la red (blogs, foros, tutoriales, etc…) no son de fiar, y en la inmensa mayoría de los casos son erróneas, no siguen ningún tipo de diseño u arquitectura de software (muchas veces por el propio diseño de hibernate), etc…
Y además, para lo que hace, es muy complicada la configuración y uso correcto.
Desde mi punto de vista, hibernate es un parche encima de otro.
Si lo que buscas es buena documentación, nada mejor JDO o cualquier otro estándar. Está muy de moda lo del “estándar de facto”, y personalmente, creo que un estándar tiene que estar reconocido por grupos de profesionales cualificados y no sólo porque sea el más usado.
Hibernate empieza a ser un estándar ahora, que implementa JPA (y por cierto, lleno de bugs).
Resumiendo, que siempre me inclino por un estándar, que es lo único que está de verdad documentado y no hay que fiarse de foros y blogs.
PD. Lo del OpenSessionInViewFilter ya no tiene nombre. Acceder a base de datos desde la vista, abriendo conexiones a cascoporro y sin control! Olé! Pero sobre gustos, no hay nada escrito (Por eso mejor tirar de estándares de verdad).