jueves
ago162012
Hibernate 4.1.6 publicado y certificación de JBCD de RedHat
Desde el curro, me ha tocado pelearme con Hibernate. Bueno, últimamente hago mucho uso de los foros (que vienen muy bien para resolver problemas en el caso de frameworks populares, pues el problema que te da a tí es muy probable que le haya ocurrido a otros, es la ventaja de estos usos)....
Que me enrollo, voy al grano, veo dos enlaces que pueden ser interesantes que creo que no habíamos comentado previamente:
Noticia sobre la versión 4.1.6.Certificación JBCD de RedHat
Saludos, Jaime.
tagged 
Hibernate 4 in orm
Hibernate 4 in orm
Reader Comments (34)
La noticia de Hibernate 4.1 es un poco vieja.
Um, no quisiera ser aguafiestas, pero hibernate va por la versión 4.1.5 service pack 1 (sí, service pack).
Hibernate ORM 4.16.Final Release.
Un comentario, y al solo efecto de generar polémica.
En mi caso, no empleo JPA, no empleo anotaciones, genero los archivos de mapeo por mano, y por reversa las clases, al igual que los script's de generación de esquema para las DB's.
Herencia, interfaces y comentarios se pueden especificar en el mapeo al igual que las claves forañas.
También genero un solo archivo de mapeo para todas las clases relacionadas lo que facilita el mantenimiento.
¿Cómo lo hacéis los demás?
Un saludo,
Efectivamente, la última versión es Hibernate ORM 4.16.Final Release.
Actualizamos la noticia.
Saludos,
@efrigerio
La única diferencia contigo es que creo un fichero por cada clase y pongo los ficheros en un paquete alternativo llamado "hibernate".De esa forma los paquetes con las clases de dominio no tienen ninguna referencia a nada sobre la persistencia.
Yo sí que uso JPA y anotaciones en las clases del modelo de dominio (como viene en todos los ejemplos y libros que he visto) pero a la larga todo el código queda horrible.
Últimamente estoy pensando en hacer lo que creo que dice logongas, dejar las Entities en una capa de persistencia completamente separada de la capa de dominio.
Esto supone más trabajo inicial y probablemente impide usar cosas como lazy-loading pero a la larga creo que será mejor desde el punto de vista del mantenimiento.
@zemi
¿Pq dices que se pierden cosas como lazy-loading? No creo que se pierda nada.
Yo tengo un paquete entity para las clases generadas por reversa.
Al igual que logongas los archivos de mapeo los guardo en un paquete separado, por lo general, con las properties o algún otro recurso que necesite.
La diferencia está en que genero un solo archivo de mapeo por grupo de clases relacionadas en lugar de uno por clase.
@zemi
Si entendí bien,
En mi caso heredo de una clase abstracta que implemente Lifecycle.
http://docs.jboss.org/hibernate/orm/4.1/javadocs/org/hibernate/classic/Lifecycle.html
Poner anotaciones en clases obviamente reduce la portabilidad entre bases de datos y deja el codigo sucio (y lo deciamos asi hace 5-6 añitos, pero la mafia de "poner anotaciones en cada parte de tu vida" querian propagar esa idea como algo bueno, hasta llenar libros). Sin duda, no pierdes nada de nada usando un archivo de mapeo ... por eso existe el mapeo, para la flexibilidad.
Buena suerte.
@lolongas
Digo que perdería cosas como el lazy-loading porque estoy pensando en separar completamente los objetos de dominio de los objetos de persistencia, es decir, no usando proxy, decorator, herencia etc... si no al estilo de los ports-and-adapters, es decir, creando los objetos de dominio a partir de las entidades después de leerlas de las bases de datos y al revés, crear las entidades a partir de los objetos de dominio, antes de persistirlas.
Ya te digo que de momento no trabajo así, que es algo en lo que estoy pensando para ganar flexibilidad y mantenibilidad.
No me refiero a separar los mapeos sino a realmente aislar el modelo de dominio completamente de las clases de persistencia. Y no sé si es una buena idea o no.
> Poner anotaciones en clases obviamente reduce la portabilidad
> entre bases de datos y deja el codigo sucio
Y que lo digas... En fin, yo me leí un libro de 500 páginas de JPA 2, escrito por uno de los creadores de la especificación, y hago todo como pone en el libro, pero cada vez me gusta menos como queda. Estoy confuso...
Es una lástima que el Exadel ORM Studio no haya tenido continuidad.
Yo fui de los que con gusto pago por una licencia, y seguiría pagando.
@datanucleus
pero la mafia de "poner anotaciones en cada parte de tu vida"
Una anécdota, y solo para seguir generando polémica.
Después del lanzamiento de EJB 3, tuve oportunidad de escuchar a Gavin King en persona.
No era tanto lo que decía sino lo que daba a entender. Tenía una actitud de....
Yo arquitecto, diseño empleando herramientas de modelado, los programas aparecen por reversa, y los programadores solo sirven para serrar espacios donde la herramienta no llegue, pero siguiendo mis indicaciones generadas como comentarios en los skeleton desde las notas de diseño en la herramienta.
En pleno auge de la XP, esta idea sonaba un tanto sacrílica.
Varios años después, ya con otro tipo de responsabilidades y teniendo que lidiar con lenguajes y compiladores humanos....
Bueno, digamos que el concepto ya no me resulta tan hereje.
:)
@zemi
Creo que no te entiendo.¿Que diferencia hay entre las entidades y las clases de dominio?Para mi son lo mismo.
@datanucleus
¿Porque dices que las anotaciones reducen la portabilidad entre bases de datos?¿Te refieres a las anotaciones de JPA/Hibernate? Pq no creo que influya en nada en la portabilidad.
Aunque me he gustado mucho tu comentario de la mafia de las anotaciones.Desgraciadamente creo que hay mucha mafia entre los vendedores de libros.
Y una pregunta a los demás,¿donde poneis todas las reglas de negocio? Con el JSR 303 no hay suficiente.Para algunas cosas yo uso los listeners de hibernate pero se podría usar una capa de facade por encima.
@logongas,
si ... las anotaciones de JPA. Lo digo porque si quieres cambiar una aplicación que ya utilisa RDBMS "X", para utilisar RDBMS "Y", tendria que cambiar las anotaciones y recompilar las clases del modelo. Hay bastante diferencias entre los RDBMS y en todas las aplicaciones que he visto alguien ha puesto cosas como nombre de columna, y si sea en mayuscula/menuscula, "columnDefinition" para que usa un tipo mas apropiado del RDBMS, y muchas otras cosas. En cambio el usuario con su mapeo podria solo cambiar el "orm.xml" y ya esta; un orm.xml para RDBMS "X", otra para RDBMS "Y", etc.
Suelo poner anotaciones basicas @Entity, @OneToOne, @OneToMany, @ManyToOne, @ManyToMany, @Id y no mucho mas. Las cosas de tablas, columnas etc va en el orm.xml ... por si acaso. Obviamente si una aplicación esta diseñada para utilisar MySQL y nunca va a cambiar, no hay problema, y el desarrolador puede hacer lo que quiere ;-) solo que mis aplicaciones no son asi.
Muy polemica :-)
La certificacion no es :
JDBC - Java DataBase Conectivity
si no:
JBCD - JBoss Certified Developer
Hay las letricas !!!
El ser humano es muy interesante y divertido porque tiene una capacidad fabulosa para el autoengaño y no, no lo digo desde la distancia, todos nos autoengañamos en ocasiones porque nos encanta seguir a una "autoridad" y asumir sus cambios de criterio de acuerdo con sus intereses como "necesarios".
Pongo mi ejemplo favorito, Spring IoC, Spring "inventó" dos cosas:
1) Un pseudo lenguaje de programación basado en XML
2) Un curioso sistema de factoría de objetos implícito indirectamente basado en el lenguaje anterior
Cuando se defendía lo maravilloso que era Spring se aludía a lo limpito de dependencias que quedaban los objetos Java, cierto, a costa de meter todas las dependencias posibles escritas en un incontrolable XML, cualquier con un poco de distancia puede ver en esos XML asignaciones a atributos, llamadas a objetos, definición de variables temporales etc etc . Ahora bien a un fanático de Spring no le cuentes que eso es programación imperativa pero en XML, y que la "suciedad" esparcida (dependencias) la has concentrado en un sólo lugar y de forma escasamente estructurada, inmantenible, indepurable, fuertemente "verboso" etc.
En mi opinión el ruido y las rigideces que ha introducido Spring ha estado muy muy por encima de sus ventajas, ahora bien había una que me dejaba sin argumento: cambias el XML y ******sin recompilar****** tienes la aplicación funcionando en un modo diferente , el argumento siempre me pareció flojo pues si ese es el objetivo quizás es más razonable usar un lenguaje no compilado o al menos "para configurar", pero desde luego era un buen argumento pues a fin de cuentas ese pseudolenguaje XML es no compilado.
Ahora bien en el momento en que se introdujeron las anotaciones como mecanismo de "configuración" y se impuso como "la" alternativa al XML, denostando lo único bueno que tenía (su cambio sin recompilar) pues se acabó con el argumento estrella.
Con ésto quiero decir que lo mejor es no engañarse, las anotaciones forman parte del código, es código y como tal introduce sus dependencias, y un modelo de datos con anotaciones JPA es un modelo de datos JPA y no puede ser otra cosa, y cuanto más anotación menos POJO y menos ortogonalidad y menos persistencia transparente que ha sido siempre el "santo grial" de la persistencia el cual, bien lo sabe Andy (datanucleus) se perdió el día en que pasó de moda el sistema de configuración en XML en JDO.
Yo personalmente no soy nada purista en esto, en la inmensa mayoría de las ocasiones las aplicaciones tienen un rango de tecnologías que raramente va a cambiar con el tiempo, persecución de la independencia entre tecnologías está bien si el precio a pagar no es muy alto, pero buscar que sólo cambiando una coma la aplicación X pase a ser Y casi siempre visto en perspectiva es un objetivo absurdo. Tengo el recuerdo de hace muchos años en una aplicación Microsoft Visual C++ teníamos la "idea" de utilizar lo menos posible la API de Microsoft por una posible portabilidad futura a "Unix" y hacíamos el canelo de usar la clase string y las colecciones de las Standard Template Library (STL) de C++ en vez de las de Microsoft que eran más sencillas y prácticas y cuando resulta que casi todas las APIs de Microsoft usaban las suyas y cuando al final en perspectiva veías que la dependencia de Microsoft gustara o no era tan brutal que el conseguir usar las STL era una verdadera estupidez.
Yo veo más la búsqueda de la ortogonalidad como un deseo de diseñar bien, de separar conceptos, para mantener mejor y evolucionar mejor no como la búsqueda del remplazo sencillo de piezas que luego nunca ocurre.
> Logongas: Creo que no te entiendo.¿Que diferencia hay entre las entidades
> y las clases de dominio?Para mi son lo mismo.
Sí, en mi código y en los ejemplos que veo en los tutoriales las @Entity de JPA/Hibernate y las clases de dominio coinciden.
Lo que me estoy planteando es ponerlas en dos capas distintas. Es decir, por un lado tengo mi clase de dominio
y por otro lado tengo otra clase, en otra capa (en otro paquete)
(con sus métodos para poblarse a partir de un objeto Company o para generarlo)
y esta última es la que tiene los mapeos de JPA/Hibernate.
Por un lado me parece sobreingenieria, pero por otro lado me parece que solucionaría algunos de los problemas que tengo (falta de flexibilidad, dificultad de mantenimiento).
Esto es lo que propone la arquitectura Ports and Adapters, aislar todo tú código del mundo exterior usando Adapters.
@jmarranz
En efecto, cuando se puso de moda Spring al principio llegué a ver aplicaciones en las que todas las dependencias entre objetos se inyectaban, lo cual dejaba un código (en XML) infumable.
Ahora Spring es muchas cosas, yo lo uso porque
- Facilita la configuración de otras tecnologías de terceros (WS, Hibernate...)
- Proporciona algunas utilidades out-of-the-box que están bien hechas (spring-security, spring-webmvc).
Es decir, lo uso para inyectar algunas dependencias externas pero nunca para inyectar dependencias entre mis propios objetos.
@logongas
Y una pregunta a los demás,¿donde poneis todas las reglas de negocio? Con el JSR 303 no hay suficiente.Para algunas cosas yo uso los listeners de hibernate pero se podría usar una capa de facade por encima.
Para validaciones de algunas cosas contra la DB, auditoría, tablas tipo autoincrementables, o algunas cosas por evento utilizo las facilidades del API de Hibernate.
Para el resto EJB o JMX según que y paraqué.
@zemi
Lo que mencionas me suena al patrón Broker DTO + persistencia, en donde el DTO hace las veces de separador entre el modelo MVC y el almacenamiento.
Jose María.
Más allá de que coincida con mucho de lo que has escrito.
No sé cómo, ni de qué forma, pero has logrado que el programa de síntesis de voz se quede sin aliento después del ******
:D
Un saludo,
Yo uso anotaciones y JPA, claro que las que uso no comprometen para nada la portabilidad de BDD ni nada parecido, nombres de tabla, columna, relaciones, obligatoriedad, clave primaria... nada específico ni de engine de JPA ni de motor de BDD. Las clases las genero con ingeniería inversa de la BDD, herramienta propia, y usando Lombok quedan limpias de polvo y paja (getters, setters, constructores, equals, hascode, toString...).
En mí entorno concreto, con eso es más que suficiente.
@zemi
Yo hacía algo muy similar al port and adapters, mi objetivo era intentar conseguir algo similar a lo propuesto en Domain Driven Design. Lo bueno del enfoque es que si lo haces bien aíslas la verdadera logica de negocio de tu aplicación de la persistencia, lo malo es que requiere más trabajo y que los ORM como hibernate dan más problemas que satisfacciones cuando usas este enfoque sobre todo en lo que se refiere al mapeo de relaciones. Una buena opción es no mapear relaciones con el ORM y usarlo sólo como un mapeador tabla-objetoDto plano, aunque claro, para esto arrastrar todo el aparataje de un monstruo como hibernate parece excesivo. (yo ahora estoy trabajando con grails contra una bd legacy y es lo que hago con gorm, no mapeo relaciones y vivo mucho más tranquilo). Para una arquitectura como esta quizas compense más utilizar algo más sencillo en la capa de persistencia, que te libre del dolor de cabeza de usar JDBC "a pelo" sin darte a cambio una migraña todavía mayor.
Yo te diria que este enfoque merece la pena si la logica de tu aplicación es compleja, si se trata de un CRUD con vitaminas y validaciones entonces no merece la pena, si se trata de algo más entonces probablemente sea buena idea.
Ahora que me estoy pegando con un legacy spring-hibernate de siete cabezas, sinceramente, es una burrada la perdida de control a la que te puede llevar un ORM (usandolo mal obviamente), da panico después de coger un objeto con tropecientas relaciones mapeadas y hacerle otras tropecientras modificaciones ver los sql que se mandan a la base de datos, en serio, show_sql=true y es todo un espectáculo jeje, el pobre compilador de querys de mysql tiene que estar echando humo xd.
En serio, la persistencia no puede condicionar de una manera tan brutal toda tu aplicación, una cosa es usar un framework que te ayude a no escribir código repetitivo de acceso a datos, y otra cosa muy diferente es que tu aplicación este construida alrededor de un concepto como la persistencia, que es importante si, pero es sólo una de las muchas partes que tiene la arquitectura de una aplicación.
>Lo bueno del enfoque es que si lo haces bien aíslas la verdadera logica
> de negocio de tu aplicación de la persistencia
Mi problema ahora es que las entidades se van haciendo cada vez más gordas con lo que el código se vuelve más rígido y "viscoso".
Por ejemplo, yo no veo del todo mal tener en la BD una tabla users con 30 columnas. (telefono del trabajo, cuenta corriente, si acepta publicidad...). Aunque siendo puristas se podría separar en varias tablas, por rendimiento y por facilitar las consultas está bien tenerlo junto.
Pero lo que me parece horrible es tener un objeto User con esos mismos 30 campos, prefiero tener un buen puñado de clases y usar composición.
Si tengo separados los objetos de persistencia de los objetos de dominio puedo evolucionar y refactorizar el dominio sin preocuparme de la BD.
Si mi User es una Entity de JPA y me piden que añada el dato nacionalidad seguro que acabo añadiendo como un campo sin refactorizar nada.
De todas formas no he trabajado así, igual luego me parecería un lío tener un modelo de dominio que no se corresponda con las tablas de la base de datos. Pero me gustaría probarlo.
>Yo te diria que este enfoque merece la pena si la logica de tu aplicación es
> compleja, si se trata de un CRUD con vitaminas y validaciones entonces no
> merece la pena
Bueno, al principio prometía ser un CRUD, pero como cualquier proyecto que perdura en el tiempo ahora tiene un montón de reglas de negocio con las que lidiar.
Dicho de otra manera, cuando empecé el proyecto JPA/Hibernate me parecía una maravilla lo limpio que quedaba todo y ahora me parece que tengo un follón de cuidado.
Si tu tabla usuario por rendimiento debe de ser una tabla con 30 campos entonces debe serlo, igual de horrible es condicionar el diseño por la persistencia que condicionar la persistencia por el diseño.
Creo que tu enfoque es el adecuado, así la clase user estaría compuesta por otros objetos (valueObjects en terminología DDD) que además serían el lugar perfecto para albergar la logica relativa a esos datos (patrón experto de toda la vida) y de esa manera construyes un dominio con responsabilidades mejor separadas (teniendo siempre en la cabeza el Single responsability principle) y de paso mejoras la encapsulación y disminuyes el acoplamiento.
Desde luego esto es mucho mejor que tener una clase user con 30 campos y 50 metodos, o la otra opción, una clase anemica (sólo con métodos get&set) y luego 50 servicios que hacen operaciones con los datos del usuario.
En mi opinión vas por el camino adecuado, aunque cueste un poco más de trabajo por lo que cuentas creo que te merecerá la pena.
@zemi estoy de acuerdo con Alfredo es horrible condicionar el diseño por la persistencia y la persistencia por el diseño (en un sentido negativo el ideal es que coincidan), si te estás planteando la necesidad de duplicar modelos de datos/dominio (llámense como se quiera) quizás te estás acercando a la situación en donde tu querido JPA no te aporta NADA y quizás un simple JDBC (o sencillo-flexible ORM sobre JDBC) te resultara más efectivo en donde via DAOs creas los objetos que necesitas como tú los necesitas (por ejemplo tu User y Address se obtendrían de ambas consultas de datos parciales a tu mega-tabla User), JPA es una herramienta no es un fin en sí mismo.
La otra alternativa la de Alfredo, es asumir el pobretón papel de tu JPA y utilizarlo como mega-sofisticado JDBC en donde tu User y Address se obtienen como una copia parcial del mega UserDB obtenido de JPA. En lo que no estoy de acuerdo es en lo malos que son los modelos anémicos pero eso es otra guerra.
El día que descubres que el método Tienda.getListaDeProductos() se trae la tabla entera en memoria asumes lo sobrevalorados que están los Hibernates y demás, y en cierto modo no es culpa de ellos sino más bien del problemón que es la impedancia objeto-relacional y también, todo hay que decirlo, el gravísimo error que cometieron los primeros ORMs (y hasta ahora) en considerar operaciones de persistencia completas, es decir el List que devuelve Tienda.getListaDeProductos() es un List que no tiene detrás un ResultSet abierto y de ahí su escasa utilidad.
@alfredocasado @jmarranz @everyone
Muchas gracias por vuestros comentarios, me aportan mucho. Llevo bastantes años en esta profesión y cada vez me doy cuenta que lo que menos domino son los fundamentos de cómo organizar una aplicación, lo que viene a ser la orientación a objetos bien usada.
Por regla general esto es algo que no se aprende:
- Ni en la universidad (enseñan los básicos de orientación a objetos pero nada de patrones o principios).
- Ni en los eventos y conferencias de programación (normalmente orientados a herramientas concretas, tecnologías y lenguajes novedosos...)
- Ni en los ejemplos tipo PetStore que no suelen estar nada bien hechos.
Debe de ser que se supone que es algo que todo el mundo sabe pero ni yo ni la gente con la que he trabajado lo sabemos.
> quizás te estás acercando a la situación en donde tu querido JPA no te aporta NADA
Hasta hace un par de años trabajaba en el típico proyecto de cientos de miles de líneas de código y usaba JDBC. Ahora uso JPA con Hibernate (ahora creo que fue un error elegir JPA, mejor haber usado Hibernate directamente).
Lo mejor de JDBC es que nosotros teníamos el control, y entonces las consultas a base de datos y el rendimiento de la aplicación eran mucho mejores que con el ORM.
Lo mejor de Hibernate es que cuando hay que hacer un cambio en el esquema de la base de datos (añadir o quitar un campo, por ejemplo) con Hibernate es inmediato, mientras que con JDBC pasábamos días repasando todas las consultas que usaban esa tabla. Cualquier cosa que hace que tu código sea difícil de cambiar te intentar evitar el cambio y en muchos casos introducir hacks en vez de refactorizar.
@zemi
Llevo bastantes años en esta profesión y cada vez me doy cuenta que lo que menos domino son los fundamentos de cómo organizar una aplicación, lo que viene a ser la orientación a objetos bien usada.
Totalmente, en realidad muy poca gente domina estos conceptos, a mi me asaltan dudas a diario que me hacen pensar "joder esto no debería tenerlo claro, ¿no debería ser algo asumido?, si no hago aplicaciones para la NASA!". Lo digo muchas veces, la complejidad de desarrollo de software no esta en la algoritmia (que es un problema más acotado y en muchas casos bien resuelto) la verdadera complejidad es estructural, lo que hace que el 99% de los proyectos que he conocido terminen mal es que cuando crecen se van de madre y ya no hay quien los mantenga.
Es una profesión muy joven, quizas todavía andamos descubriendo las mejores formas de hacer las cosas y probamos de un modo y nos equivocamos, luego de otro modo y nos volvemos a equivocar jeje. Claro que si a los 30 como mucho todos nos convertimos en jefes de proyecto y dejamos de programar... pues bien, que vengan los nuevos y repitan los mismos errores... pero como dice jmarranz, esto es otra guerra...
@jmarranz
quizás te estás acercando a la situación en donde tu querido JPA no te aporta NADA y quizás un simple JDBC
Por ejemplo con groovy-sql:
sql.eachRow("select bla,bla") { row -> productos << new Producto(row) }
con eso ya tienes un "mapeador" simple tabla-objeto. En java, nosotros teníamos unas pequeñas utilidades sobre jdbc que nos permitían escribir código muy similar al que he puesto antes (con clases anonimas y mapeando a mano eso si)
Tienda.getListaDeProductos() es un List que no tiene detrás un ResultSet abierto y de ahí su escasa utilidad.
Hombre es que tampoco es tan facil dejar el resultset abierto, si estoy haciendo una app web y quiero hacer algo tan simple como un listado con paginación si me guardo esa lista que internamente tiene el result set abierto en sesión me cargo la posibilidad de desplegar en cluster por un lado y me como las conexiones a la bd por otro y adios escalabilidad.
Pero claro cargar la lista completa en memoria es un despropósito todavía mayor, por cosas como esta os decía antes que yo casi nunca mapeo relaciones y vivo mas tranquilo.
@zemi "la verdadera complejidad es estructural, lo que hace que el 99% de los proyectos que he conocido terminen mal es que cuando crecen se van de madre y ya no hay quien los mantenga."
Shhhh calla, no sea que alguien se entere y deje de reclutar gente basándose en el único criterio el número de años utilizando la estúpida API X, pues según este criterio pasado el año ya eres un fucking master del software tipo X y al segundo año ya "pa jefe" de proyectos experto en X y así nos va, un sector-guardería reinventando la rueda todos los días (anda pero si rima).
Te recomendaría
http://en.wikipedia.org/wiki/SOLID_(object-oriented_design) pero no lo tomes como dogmas sagrados que hay que seguir porque lo diga el Paquito el Chocolatero de la OOP, que hay algunos que ven el mundo como bueno/malo, bien/mal y en esa búsqueda del "bien hacer" pierden el norte. Se trata de gestionar la complejidad aunque habitualmente sea a costa de introducir más complejidad, pero teniendo muy muy claro que la peor complejidad que existe ES EL CAOS.
@alfredocasado "Hombre es que tampoco es tan fácil dejar el resultset abierto, si estoy haciendo una app web y quiero hacer algo tan simple como un listado con paginación si me guardo esa lista que internamente tiene el result set abierto en sesión me cargo la posibilidad de desplegar en cluster por un lado y me como las conexiones a la bd por otro y adios escalabilidad."
No no hablo de eso, hubo un tiempo (en el ppio de los tiempos) en el que al principio de la request se abría una transacción, se hacía lo que se tenía que hacer incluida la generación de HTML y al final de la request se cerraba la transacción. Una transacción, si es JDBC normal y corriente (no hablo de JTA aunque no es demasiado diferente) implica abrir la conexión al ppio de la transacción y cerrar al final (por supuesto hablo de un pool de conexiones).
No tengo que claro que haya que volver a ese enfoque tan radical (o sí habría que echar números y comparar con lo que hacemos ahora), pero lo que es cierto es que en esa request con una conexión viva y ResultSet vivos se cogería de la BD lo que se necesitara, se podría hacer mucho más "lazy loading" de lo que se hace hasta ahora (porque un List.size() haría una consulta en la base de datos y no un size de la colección después de traerse la tabla entera como ocurre ahora), incluso podrías darte el lujo de hacer un "select * from table" para sólo mostrar los 5 primeros resultados, ahora no tienes más opción que hacer consultas paginadas, olvídate casi siempre del Tienda.getListaDeProductos() por tanto la mayor parte de las relaciones que modelas con tu ORM JPA/Hibernate son simpáticas pero prácticamente inútiles.
> al principio de la request se abría una transacción, se hacía lo que se tenía que
> hacer incluida la generación de HTML y al final de la request se cerraba la transacción
Esto es más o menos el patrón o antipatrón OpenSessionInView (OSIV)
Un día me entretuve leyendo todo lo que encontré en los foros de Spring sobre esto, y gente que sabe de esto mucho más que yo, por ejemplo Costin Leau, no se decantaba sobre si usarlo era buena idea o mala idea.
Es otra cosa que me gustaría probar, pero claro, no se puede probar en 5 minutos, porque hay que cambiar muchas cosas en la aplicación.
¿Pero es que no lo hacéis así? Yo sigo basándome en las peticiones como unidades, o menores, y, como decís, lo de traerse la tabla entera en memoria es cuestión de mal uso, por que vamos, opciones para paginar sin traerse la tabla entera las hay, igual que opciones para traer objetos sin cargar todos los relacionados, o al revés, cargar los relacionados si hacen falta pero con un JOIN para no tener el problema de N+1 queries.
Quejarse de que eso ocurre sin usar los medios disponibles que hay para evitarlo... no le veo el sentido.
zemi
los principios que todo desarrollado deberían conocer son
en el aspecto de como organizar las clases son solid
en el aspecto de como organizar los componentes si les llama principios de empaquetado
en lo que se refiere a como crear una arquitectura hay varios tipos
arquitectura en pipes ,en capas (layers),orientado al modelo (mdd) o (mda) ,context data interaccion,entity boundary controler
Otro tema es mi apreciaron critica al respecto.
todo desarrollador que se respete debería conocer a fondo los principios que he mencionado pero no debería creer religiosamente en ellos es decir que analice y piense si realmente son útiles para cada ocasión es decir no tener una fe siega y considerar esos principios como el un fin si no como un medio para lograr un buen software.
No existe soluciones buenas ni religiones correctas todas las decisiones que tomes son fundamentalmente malas me corrijo son extraordinariamente malas (todas tienen desventajas) toda abstracción es imperfecta(leacky abstrasion)y a lo que puedes aspirar es escoger la opción menos mala dependiendo del contexto en que te encuentres quiero decir ser realista y pragmático.
otro tema es que si estudias mdd (model driven development) tendrás ventajas por que esta arquitectura es esencialmente orientada a objeto su principal aporte es que clasifica los objetos en unos grupos bien diferenciados y que características deberían tener para su funcionamiento mas optimo y mantenible
@Komorr
Yo sólo me he quejado de mi propia ignorancia. De todas formas si te fijas en el enlace que he puesto, verás que gente que sabe de esto no se pone de acuerdo en si usar el OSIV es buena idea o no.
Mi mayor miedo con el OSIV es que rompe la separación en 3 capas, a nivel de código queda limpio porque todo se hace con proxies u otro mecanismo, pero si luego llegas un día y quieres poner por ejemplo una capa de caché en medio no funcionará porque cachearás proxies en vez de datos.
No había leído bien, creía que se refería a otra cosa, por que a mí lo de la OSIV siempre he tenido claro que no me gusta y no lo uso :). A mí lo de que si no lo haces así, al modificar la vista has de modificar el modelo para mostrar mas o menos cosas... por supuesto, lo veo normal... si no, significaría que la vista es toda tu aplicación.
A mi personalmente me parece un mecanismo cómodo para evitar tener que tratar el tema de las conexiones, el lazy-loading/eager-fetch al que luego se le ha buscado justificación ideológica. Pero vamos, es por comodidad.