05-12-2008 Raul Vicente
Hace tiempo que no escribo ya que últimamente ando batante liado y reconozco que estoy un poco oxidado, pero Luis me ha pasado un artículo que me ha hecho reflexionar. El artículo habla de la capa de Persistencia y de las posibilidades que hay en Java actualmente, cita entre otros frameworks a Hibernate, Toplink, Enterprise Object Framework e iBatis. Estas herramientas ORM han surgido en los últimos tiempos con la promesa de que harían nuestra vida mucho más fácil. Yo, en concreto, he trabajado con Hibernate e Ibatis y reconozco que Ibatis me parece más simple y me gusta más que Hibernate para proyectos de mediana envergadura.
Nadie puede negar que hay mucho trabajo detrás de estas herramientas, y que combinadas con Spring convierten un código “spagetti”, gracias en parte al diseño de JDBC, en algo limpio intuitivo y sin lógica de control que pueda desviar nuestra atención de la lógica de negocio, pero ¿ a qué precio?.
Esta claro que una capa de Persistencia es necesaria, de acuerdo, es inegable a su vez que la combinación de estas herramientas es mejor que no usarlas, pero ¿ no esla curva de aprendizaje no es demasiado alta? En el caso de Ibatis no lo es mucho si uno ha bregado antes con frameworks que usen configurations, pero en el caso de Hibernate es más que pronunciada. Al final, no nos engañemos el problema son los malditos XML de configuración y los miles de errores que uno ha de solucionar cuando empieza a trabajar con ellos y la gran mayoría, por desgracia, no son depurables en tiempo de compilación.
En mi opinión el cogerle la mano a eso el quid de la cuestión, y lleva demasiado tiempo. ¿No hay una forma más fácil de hacer esto que, además, me permita tener la lógica de mi aplicación en mis clases y no dividida a través de N mil ficheros de configuración?
Si uno utiliza Spring, Struts -con sus pulugins Validator y Tiles- e Ibatis el cielo se le viene encima, porque estamos hablando de 6 ficheros de configuración más todos los ficheros de mapeo de Ibatis – uno por cada tabla si uno quiere claridad -, con lo que la depuración se hace costosísima.
Reconozco que siempre he sido partidario de las conventions y que no sé si la solución es utilizar annotations u otra cosa, pero en mi opinión, en esta dirección no se está acertando. Hay que copiar a otros lenguajes lo que tienen de bueno y las Conventions son algo mucho más positivo que los XML de configuración. Creía que los nuevos EJB’s iban a ser la solución, pero parece que van a ser una mezcla entre Spring e Hibernate así que mi gozo en un pozo.
Me gustaría saber vuestra opinión para saber si estoy solo en esta guerra, o por el contrario, la gente piensa que se tiene que poder hacer esto de una manera más fácil.
Os dejo el enlace del artículo que ne leído:
http://fromapitosolution.blogspot.com/2008/12/criticism-of-java-persistence.html
1. caente | diciembre 5th, 2008 at 10:38 pm
“Reconozco que siempre he sido partidario de las conventions y que no sé si la solución es utilizar annotations u otra cosa”
No sé si es la LA solución, pero definitivamente usar annotation en hibernate y/o toplink reduce a 0 el uso de XML(bueno excepto el persistence.xml).
Te recomiendo darle un vistazo, cuando le cojas las vuelta te vas a dar un alegrón
2. Black Hole | diciembre 5th, 2008 at 10:57 pm
La verdad es que yo le he empezado a tener manía al desarrollo con todos estos frameworks por tener que pelearme con sus malditos ficheros de configuración :/
3. ubersoldat | diciembre 6th, 2008 at 4:22 pm
concuerdo con caente, utilizando las anotaciones de JPA y de EJB te olvidas de los ficheros de configuración. En mi caso, sólo me queda tocar persistence.xml y los XML’s de configuración de Jboss.
Lo único que puedo criticar de JPA en general, es que las NamedQueries no son chequeadas durante el compilado, por lo que sabrás que tu query está mal formada cuando te hayas dado la hostia.
Ah! Y que no puedes tener queries como “findUser” en distintas entidades. ¿De qué va eso?
En el caso de Hibernate, me molesta la dificultad de encontrar la documentación de las propiedades que puedes utilizar en el persistence.xml, lo cual en general en Java es una pena.
Saludos
4. Raul | diciembre 8th, 2008 at 4:57 pm
Buenas a todos,
al final parece que las annotations son una solución intermedia, al principio cuando yo las utilice lo que hacían era añadir un paso de compilación y auto-genear los XML, si vosotros me decís que ahora se han reducido los XML’s a uno vamos avanzando.
De todas maneras me sigue pareciendo una pena que no se puedan detectar los errores más que en tiempo de ejecución ya que el tiempo que se pierde es muchísimo cuando uno empieza con estos frameworks.
Muchas gracias por colaborar.
5. daniel | mayo 14th, 2009 at 5:32 pm
bueno, yo yo he pasado por varios framework, con figurando xml. con struts, spring, jsf. entonces ahora estoy con seam. y ese tiene una pontecialidad enorme revisen. esta pagina y metanse a ebj 3.0
http://www.seamframework.org/
aca te ahora los xml. pero eso si que tiene que tener un modelo de datos en orientacion objetos, y no en entidad relacion. porque se demoria mucho al levantar el servidor.
6. Edwin Plauchu | junio 10th, 2010 at 12:51 am
La verdad es que termino mucho mas rapido implementandome un MVC casero sobre un servidor J2EE
que usando esos frameworks plugleables via xml…..
Se tarda bastante el arranque de la integracion de todo lo que le metas a tu proyecto…..
En lo particular hibernate spring me parecen un caos….
Solo por ahorrarnos SQL terminanos haciendo aplicaciones bastante gordas…. sin mencionar que por ahi un query de hsql te trae hasta lo que no… si no te pones abusado….
Les recomiendo aprender patrones de diseño y montarce su solucion a mano….