En JavaWorld se publica un resumen donde se explican rápidamenete las siguientes tecnologias/frameworks:
El artículo trae ejemplos prácticos, recomendable para programadores principiantes que aun no utilizan estas herramientas.
Enlace del artículo: http://www.javaworld.com/javaworld/jw-07-2008/jw-07-orm-comparison.html
Saludos,
Ernesto Campohermoso.
Ninguno, gracias :-) salvo que he utilizado los tres, y unos mas.
Porque limitar tu aplicacion desde el principio? No quieres escribir la aplicacion con la capacidad de utilisar otro base de datos en el futuro, o otro lenguaje de "query". Muchas aplicaciones de JEE se hace falta comunicar con LDAP, o XML. Porque pensar en isolacion sobre ese RDBMS y no tener el mismo API para todos?
El articulo dice "... si necesitas persistir a otros tipos de bases de datos como XML , luego JPA no es la respuesta" pero en DataNucleus utilizamos JPA (y JDO) para persistir datos a XML (o otros bases de datos) sin problemas. Bueno JDO seria mas conveniente, pero es posible.
JDO, aunque en desuso es el mejor ,el mas flexible.
El mejor ORM , pues KODO en su version 3.4.
requisito muy común el tuyo, por cierto...
jpox, tengo una duda: ¿DataNucleus necesita un agente java (-javaagent) para la carga perezosa en relaciones uno-a-uno y muchos-a-uno al igual que toplink (ver http://weblogs.java.net/blog/cayhorstmann/archive/2006/06/the_innermost_s.html)?
@supertorpe
DataNucleus utiliza cambios de bytecode (como Kodo, Versant OpenAccess, XCalia, y unos mas). Podrias hacerlo justo despues de la compilacion, o podrias utilizar ese "javaagent" si sea mas conveniente. Hacerlo con javaagent tiene desventajas (de rapidez, justo al momento en que quieres que la applicacion va mas rapido). Hay muy buenas razones por utilizar esos cambios al bytecode - deteccion de cambios en los campos, y la carga perezosa. Si no, la solucion de persistencia tendria que utilizar refleccion, y es mas despacito.
La explicación simple de las diferentes soluciones esta bastante bien para hacerse una idea, si no sabías de qué iba la cosa. En cambio algunas de las conclusiones me parecen bastante "cogidas por los pelos".
Una pena que JDO haya "desaparecido del mapa" para muchos escritores de artículos.Yo nunca he tenido que cambiar una aplicacion a usar algo que no fuera RDBM, ni utilizodo LDAP o XML como persistencia, al menos de momento, pero siempre viene bien tenerlo como opción.
En el framework que usamos tenemos "integrado" JPA e Hibernate, quizá sería interersante añadir Ibatis y JDO pero sin "caso de uso", es cuestion de tener tiempo y ganas :).
¿Las librerias que necesita DataNucleus estan en algun repositorio Maven? ¿Hay tareas Ant para hacer el post-compilado? (en el ejemplo he visto que en modo comandos pero no pone si hay tarea Ant especifica)
Tengo una aplicación de ejemplo con 6 implementaciones diferentes para la lógica, y lo tengo todo automatizado, incluidas las dependencias, asi que me facilita las cosas si estan así :)
Aunque sea mezclar un poco las cosas ... yo no estoy de acuerdo con tener que elegir, me explico, por ejemplo Hibernate soporta JPA, ¿por qué no usar JPA y para las limitaciones de este Hibernate? Si ... nos salimos del estándar, pero por el momento y en espera del JPA 2.0 no tenemos muchas más opciones. Lo mismo pasa con Apache OpenJPA framework que nombro mucho y que es uno de los más desconocidos (o esa sensación me da a mi) en esto de la persistencia, Apache OpenJPA implementa JPA 1.0 y además provee de diferentes anotaciones para hacer cosas que el estándar no cubre. Además KODO es una capa que se construye por encima de este framework.
Yo apoyo usar el estándar siempre que nos sirva y cuando no, salirnos de este :)
A mí me gusta distinguir entre dos casos:
a) Cuando necesitamos una base de datos para una aplicación web
b) Cuando necesitamos una aplicación web para una base de datos
El caso "a" se da, por ejemplo, cuando vamos a desarrollar un foro y necesitamos una base de datos para almacenar los datos del foro.
En el caso "a" lo más cómodo y eficiente suele ser JPA / Hibernate.
El caso "b" es el típico en la informática corporativa: Una corporación mantiene los datos corporativos en una base de datos y se van desarrollando aplicaciones web alrededor de esta base de datos para gestionar los datos, realizar consultas, etc.
En el caso "b" no tiene ningún sentido utilizar JPA / Hibernate, puesto que la base de datos no va a cambiar y lo más cómodo y eficiente es trabajar con JDBC y SQL directamente (salvo en el caso de bases de datos de mainframes de IBM, que supongo que utilizarán librerías propietarias para conectar al mainframe desde java).
Me resulta curioso que nadie defienda el uso de JDBC y SQL "a pelo", cuando es la opción más utilizada (y, en mi opinión, la opción más adecuada con mucha diferencia respecto al resto) en el mundo del desarrollo de aplicaciones web corporativas, ya sean de uso interno o de cara a Internet.
Terminator (para que luego no digáis que no me identifico).
Me parece muy interesante el comentario de Terminator. Me aclara bastante el qué usar en las aplicaciones que estamos ahora desarrollando.
Y si trabajas con JDBC y sql, ¿existe alguna librería o programa, que te crea automaticamente, partiendo de la base de datos, las sql del crud? Es en lo que más tiempo pierdo. Estoy haciendo un programín chorra para que me automatice un poco esa tarea, pero si ya hubiese algo hecho no pierdo el tiempo en ello.
Jose.
Hombre, si la aplicacion crece lo suficiente, se tiende a organizar los SQL en un sitio para poderlos mantener más facil... y practicamente eso es Ibatis, que es una capa bastante fina, pero en vez de pasar a Ibatis se acaba reinventando algo similar poco a poco.
Y el JDBC para aplicaciones grandes, sin centralizar, tiene los problemas por los que existen estas soluciones, los SQL pueden acabar dispersos por todo el codigo y es más dificil de mantener, cambiar de BDD puede ser más costoso... Y que sea la opcion más utilizada, si es que lo es*, no tiene nada que ver con que sea la solución más adecuada o que haya que defenderla.
*Por estos lares la tendencia en empresas que he visto es Hibernate o PLSQL, pero no JDCB + SQL a pelo. Pero no digo que en otros sitios no se use mucho.
Estoy de acuerdo con terminator, aunque sean cirscumstancias concretas es bastante habitual.
En grandes corporaciones a menudos los datos maestros estan en varias mega bd tipo db2, oracle y entornos tipo sap. Si tienes que hacer ciertas consultas a tablas maestras algunas de las cuales tienen del orden de 60 o 100 millones de registros y algunas de las relaciones que has de montar son realmente complejas, con mapeo de objetos lo veo bastante crudo y arriesgado. A veces la diferencia entre que la query acabe o no acabe esta en como haces la select. Y como la BD no es tuya, ni siquiera esta en el pais, no puedes ir y empezar a trastear con indices y demas. Tienes que preguntar y vigilar que metes en las queries.
Para esto ibatis me parece perfecto, sino al final te acabas montando lo mismo a mano. Si has de hacer una aplicacion web mas o menos crud contra tu mysql, es otra historia.
victor
> Apache OpenJPA implementa JPA 1.0
> Además KODO es una capa que se construye por encima de este framework.
Lo que me interesa es lo que va a pasar con OpenJPA como ya Oracle no va a desarrollar mas a Kodo. Como unos personas de BEA contribuyen a OpenJPA y ya trabaja por Oracle, vayan a terminar?
Si es un apena que KODO vaya a desaparecer..
Es sin lugar a dudas el mejor ORMapper.
Esto es algo que no logro entender , porque se destruyen aplicaciones tan buenas como KODO, sin dudas mucho mejor que TopLink, y muchisimo mas sencillo , potente y versatil que Hibernate.
Lo mismo pasa con el standard JDO, (es una especificacion muy madura usada hasta el cansancio), solo se la tapó con un estandard de poco pelo como JPA , lleno de instrucciones directas a la base relacional, baaaa ... una porqueria.
Al perecer los intereses economicos logran convencer a las revistas , distribuidores , empresas de que se guian por el dicho:
Comamos mierda , dos millones de moscas no pueden estar equivocadas.
Terminator,
A utilizar JDBC a pelo es preferible utilizar IBatis, puesto que lo que te permite hacer es centralizar tus SQLs en archivos XML que son faciles de leer y mantener, además que te permite utilizar Binding Variables facilmente. Por otro lado para aplicaciones donde la BBDD existe antes que la aplicación web y tienes tablas con millones de registros IBatis te permite colocar hints para indices y otras soluciones propietarias del RDBMS. Respecto a la generación de queries CRUD, IBatis viene con una herramienta llamada Abator. Una de las ventajas de IBatis es que tiene una curva de aprendizaje pequeña lo cual es valorable cuando el equipo de desarrollo es grande y hetereogeneo.
Respecto a lo de "limitar la aplicación" utilizando Hibenate o JPA (más alguna implementación) , creo que no es tan así, puesto que en la experiencia personal ninguna aplicación necesito persistir a XML o a un LDAP, no creo que estas aplicaciones vayan a cambiar en este sentido por lo tanto no estan limitadas, creo que mantener la simplicidad es lo mas importante.
De todas maneras creo que el articulo esta enfocado a programadores que aun siguen progrmanado a pelo JDBC y desconocen las posibilidades existentes (viene bien conocer otras como DataNucleus).
Saludos,
Ernesto.
Para ernesto y los demás defensores de iBatis:
Efectivamente, iBatis te puede facilitar bastante la vida si tienes que trabajar directamente con SQL. No obstante, no hay nada malo en prescindir de iBatis y trabajar directamente con JDBC y SQL siempre y cuando seas un poco ordenado y metas las sentencias SQL en DAOs u otras clases de servicio construidas para ello. ¡Lo de meter sentencias SQL dispersas por todos los lados ya no lo hace nadie, je, je!
Personalmente, con el fin de ahorrarme una capa, no uso iBatis.
Por cierto, en Java 6 estuvo a punto de entrar una característica (SQL EoD) muy parecida a iBatis pero con anotaciones, de hecho, en las primeras betas de Java 6 estaba metida. Por desgracia, la quitaron (probablemente para no hacer competencia a la "estrella" JPA) a última hora. ¡Qué pena! Han intentado continuar con la idea en eodsql.dev.java.net, pero, claro, al no ser una característica integrada en Java, no la usa ni el gato. Lástima.
Terminator.
De acuerdo con terminator
A mi me ha tocado desarrollar aplicaciones del tipo B. Y La herramienta que he utilizado ha sido IBatis. Antes pase por SQL a pelo, pero comenze a utiliza IBatis y me gusto mucho que la adaptacion del equipo de desarrollo fue muy rapida, ademas los archivos centralizados hacen que el mantenimiento sea mas facil.
Para Anonimo 31/07/20087
En mi busqueda de alguna herramienta para hacer CRUD rapidamente en aplicaciones pequeñas me encontre esta herramienta: sql2java http://sql2java.sourceforge.net/ Checala. La he usado poco, pero me ha sacado de algunos apuros cuando te piden desarrollar algo que era para ayer.
Saludos
pacovr
Y si trabajas con JDBC y sql, ¿existe alguna librería o programa, que te crea automaticamente, partiendo de la base de datos, las sql del crud? Es en lo que más tiempo pierdo. Estoy haciendo un programín chorra para que me automatice un poco esa tarea, pero si ya hubiese algo hecho no pierdo el tiempo en ello.
Precisamente, lo bueno de trabajar con JDBC y SQL "a pelo" es que puedes dedicar tiempo (no "perder tiempo" ;-) ) a las sentencias SQL. De todas formas, tal como han dicho en otros comentarios, si quieres, puedes usar iBatis o bien el JdbcTemplate (y clases similares) de Spring.
Tal como he comentado, yo prefiero trabajar directamente con JDBC y SQL (ordenadamente, sin meter SQLs "dispersos" por ahí, claro). Lo más importante que hay de tener en cuenta al trabajar directamente con JDBC y SQL es que tienes que liberar la conexión en el finally, y también es muy conveniente que el periodo de tiempo de ocupación de una conexión (el "try") sea lo más corto posible; si no, los DBAs te darán un tirón de orejas. ;-)
Terminator
Es lo de siempre: depende de a qué lo quieras aplicar, del caso concreto. Para mí iBatis está bien cuando ya existe la base de datos y sobre todo si el diseño está mal. Intentar mapear eso con JPA/Hibernate es un infierno y no tiene mucho sentido. Pierdes muchísimo más tiempo del que ganas e incluso puedes empantanar al equipo.
Hibernate es muy útil cuando comienzas la aplicación desde el principio y tienes libertad para crear el modelo relacional en la bd. De todas formas la gente utiliza Hibernate de dos formas: para además de mapear los objetos hacer la aplicación agnóstica de la base de datos (cuando vas a distribuir tu aplicación entre clientes con diferentes plataformas) y como utilidad para acelerar el desarrollo, añadir limpieza y facilitar los refactorings en un proceso evolutivo contra un gestor específico de bases de datos (el caso típico corporativo).
En el último caso, JPA/Hibernate es sólo una herramienta para aplicar en donde facilite el trabajo, no una religión a seguiraunque sea contraproducente. Puedes y debes seguir usando SQL en una aplicación mapeada si hace falta, y extensiones de tu gestor de bd, y procedimientos almacenados. Hay mucho trabajo detrás de Hibernate pero también de las extensiones de Oracle -por poner un ejemplo- para acelerar el acceso a la información.
Al final la base de datos siempre sobrevive a las aplicaciones que la usan.
La empresa para la que trabajo realiza proyectos para empresas como vodafone, endesa, gas natural, telefonica, orange...y todavia utilizan JDBC y Sql a "pelo". Todavia veo lejos el dia en que grandes empresas que tienen bbdd de millones de registros y llevan un monton de años con aplicaciones a las que no paran de hacerle evolutivos y evolutivos vayan a rehacer sus docenas y docenas de aplicaciones para utilizar tecnologias nuevas.
La empresa para la que trabajo realiza proyectos para empresas como vodafone, endesa, gas natural, telefonica, orange...y todavia utilizan JDBC y Sql a "pelo".
Todavia veo lejos el dia en que grandes empresas que tienen bbdd de millones de registros y llevan un monton de años con aplicaciones a las que no paran de hacerle evolutivos y evolutivos vayan a rehacer sus docenas y docenas de aplicaciones para utilizar tecnologias nuevas.
Todavia veo lejos el dia en que grandes empresas que tienen bbdd de millones de registros y llevan un monton de años con aplicaciones a las que no paran de hacerle evolutivos y evolutivos vayan a rehacer sus docenas y docenas de aplicaciones para utilizar tecnologias nuevas.
Eso es normal, independientemente de que sea JDBC, Ibatis, Hibernate o YoQueSeAPI. Es inercia empresarial y tiene sus razones. Pero claro, no todo el mundo es ese tipo de empresa y afortunadamente hay donde elegir :).
Yo para evitarme lo de olvidarte de hacer el devolver la conexion etc. lo que hago es encapsular el acceso a todo eso en una clase y le mando "comandos" que son clases que implementan una interfaz. Asi seguro que no me olvido. El mismo "patron" usamos con Hibernate/JPA para no olvidar cerrar la sesion.
Pero claro, no todo el mundo es ese tipo de empresa y afortunadamente hay donde elegir :).
Menos mal todavia podemos elegir. Porque trabajar debe ser placentero (programar no es la excepcion), hasta el momento he tenido la suerte (si se podria llamar asi) a realizar proyectos desde "cero". Si no pudiera elegi, me dedicaria a otra cosa, tal vez Networking jejeje.
En el proyecto que estoy actualmente me pidieron que hiciera una app igual a la que usan pero desde cero (la que tienen esta colapsando, es una bomba de tiempo) y full web, con las "mismas" funcionalidades y muchas nuevas pero con la condicion de que ciertas partes de la BD original tenian que rescatarse (inventarios, proveedores, insumos,y otras). La migracion de esas partes de la BD original (una obra de arte disfuncional, abstracta e inmundamente diseñada, me deprime xD) la realice exitosamente creando una pequeña aplicacion puente (la llame MigratorX) que crea una unidad de persistencia JPA con mi modelo OO y una conexion pura JDBC y con SQL a pelo para consultar la BD original y a partir de simple datos construi objetos de dominio (JPA puro). Bueno pa no alargar tanto el cuento quedo la BD JPAda hermosamente creada y con integridad referencial muy muy buena.
Lo que me interesa es lo que va a pasar con OpenJPA como ya Oracle no va a desarrollar mas a Kodo. Como unos personas de BEA contribuyen a OpenJPA y ya trabaja por Oracle, vayan a terminar?
Como OpenJPA es un proyecto de Apache esas cosas no van a hacer que desaparezca; además, y sin saber qué va a hacer la gente de Oracle Bea, hay más gente colaborando en el proyecto (IBM y Sun por ejemplo). Viendo cómo se mueve el proyecto actualmente puedo decir que está muy vivo, hace un mes salió la versión 1.1 y hace unos diás laversión de mantenimiento 1.0.3 y ahora estan preparando la release de la versión 1.2
PD Por el momento gente que trabaja para Oracle Bea sigue colaborando con el proyecto de forma muy activa.
eodsql.dev.java.net
Guau!!! Me ha parecido muy simple lo de las anotaciones en SQL. ¿Hay alguna posibilidad de que lo metan en el Java 7?
Bueno, si no para otra cosa, al menos el artículo sirvió para anirmarme a darle un empujón y a tengo integración fácil en nuestro framework para Ibatis. Otra herramienta más a la cesta :D, para cuando tenga que atacar las BDD corporativas "complejas".
bien bien, yo tambien aprendi y me anime :D
Por cierto, para los que ya usan Hibernate y se sienten bien con el pero necesitan algun dia particionar una BD (particionamiento horizontal, varias BD una app) les presento:
Hibernate Shards: http://www.hibernate.org/414.html
Un framewokr especializado en esa tecnica de partir una BD en varias, como ellos dicen si ya sabes Hibernate ya sabes Shards y ya sabes partir una BD en varias. Muahaha
¿¿Algun otro ORM soporta eso??
¿¿Algun otro ORM soporta eso??
Los chicos de Apache OpenJPA tienen algo parecido, de hecho el que lo desarrolló se basó en Hibernate Shards. Más información aquí
ahh interesante.. :D
A mi esto me parece una barbaridad dicha desde la ignorancia supina.
"Me resulta curioso que nadie defienda el uso de JDBC y SQL "a pelo", cuando es la opción más utilizada (y, en mi opinión, la opción más adecuada con mucha diferencia respecto al resto) en el mundo del desarrollo de aplicaciones web corporativas, ya sean de uso interno o de cara a Internet."
Anónimo del día 06/08/2008 a las 10:01, a mí me parece una barbaridad que digas que es una barbaridad el usar JDBC y SQL "a pelo".
El usar JDBC y SQL "a pelo", con los accesos a la base de datos bien implementados, dentro de DAOs u otras clases de servicio, es la solución más eficiente (siempre y cuando se use un pool de conexiones adecuado, claro). ¿Por qué no te gusta esta estrategia? ¿Acaso no te gusta porque hay que recordar que se han de liberar las conexiones en los finally de los try? Si es así, entonces te diré que no es tan complicado recordarlo; es más, hay otros tipos de recursos que también se han de liberar o cerrar en los finally (ficheros, conexiones ftp, conesiones http, etc.). Y, si el problema es que no te gusta el SQL, entonces te diré que si vas a trabajar como informático en el mundillo corporativo, tendrás que aprender SQL "sí o sí".
En cualquier caso, me remito a lo que dije en el comentario del día 31/07/2008, a las 11:49.
Terminator.
IBATIS por lejos el mejor y mas practico, si practico y simple, una vez lei un libro metodologias agiles y decia algo como este: SI AL FIN DE DIA TU CODIGO NO ES LO SUFICIENTEMENTE SIMPLE, ENTONCES BORRALO Y EMPEZA DE CERO..... tambien decia ... SI ALGO PUEDE HACERSE MAS SIMPLE ENTONCES TIENE QUE SER SIMPLE, TAN SIMPLE COMO SE PUEDA.... cito esto porque para mi IBATIS es simple, hace lo que necesitamos, nos mapea de forma SIMPLE nuestros objetos y tablas de base de datos, dando completa libertad y sin ser intrusivo en el diseño de la BD, no interesa que sea o como este el diseño mas si no es nuestro y debemos respetarlo, con poquito codigo tenemos nuestros POJOS andando y andan no es teoria de lo objetual y lo bonito de moda. Las anotaciones estan muy bonitas y pueden decorar el codigo de un programador tipo PICADOR de codigo muy bien y hasta se puede decir que es un GURU, pero la verdad me parecen intrusivas tambien, yo modifico XML de ibatis y de Spring, nada mas, las clases se cambian de un lado a otro y el codigo ni se entera. Son bonitas y muy utiles para algunos casos, pero el exeso de anotaciones hace que el codigo se acople al destino, a la estructura a lo que sea. Mi clase puede ser muy distinta a la entidad , una entidad compleja y compuesta, pero con ibatis se carga rapido y funciona. Alguien probo hacer Querys complejos con subconsultas y otras variantes con Anotaciones en Hibernate,,, bueno hacelo lo mismo en ibatis , y creo que en 5 min logras lo que en Hibernate 5 Horas o mas. Para mi es exelente. y Ibatis+Spring es perfecto - ( los XMLS, bueno hay muchas cosas pero tu aplicacion puede hacer CRUD de lo que quieras, desde TXT hasta LDAP si utilizas el patron correcto y las interfaces apropiadas ). Digamos DAO para ser concretos, simplemente con 30 seg de modificar un XML en Spring ya tenes un POJO apuntado a LDAP o a ORACLE, o a un TXT o a un Mock. y si tu Base de Datos te puede dar XML entonces con Ibatis Tambien lo podes leer. y algo muy importante, una aplicacion del mundo real no se cambia de un dia para el otro en una gran empresa de base de datos Oracle a Postgress, NO NO NO NO... es mas yo a una aplicacion estrable no la cambiaria de motor sin un buen testing y revision de todo. No me gusta no saber que hacen con mis datos algunos framework, los datos son lo mas importante y lo que mas tenemos que cuidar en nuestra aplicacion, la magia puede tener un precio muy alto....
Saludos a todos.
Los estandares no siempre son lo mejor, si no miren WebBean, yo me quedon con Spring, y para los datos lo que sea mejor segun la naturaleza de los mismos. Ibatis para BD esta bien.
Escribe tu comentario