PDF de programación - Persistencia de Objetos Java: El Camino hacia Hibernate

Persistencia de Objetos Java: El Camino hacia
Hibernate

Si estás trabajando con programación orientada a objetos y bases de datos relacionales,
seguramente habrás observado que estos son dos paradigmas diferentes. El modelo
relacional trata con relaciones, y conjuntos -- es muy matemático por naturaleza. Sin
embargo, el paradigma orientado a objetos trata con objetos, sus atributos y asociaciones
de unos con otros. Tan pronto como quieras persistir los objetos utilizando una base de
datos relacional observarás que: hay una desaveniencia entre estos dos paradigmas, la
también llamada diferencia objeto-relacional. Un mapeador objeto-relacional (u ORM para
abreviar) nos ayudará evitar esta diferencia.
Bien, ¿cómo se manifiesta esta diferencia? Si tienes objetos en tu aplicación y algunas
veces alcanzas el punto donde quieres que sean persistentes, normalmente abrirás una
conexión JDBC, crearás una sentencia SQL y copiaras todos los valores de tus propiedades
sobre la selección. Esto podría ser fácil para un objeto pequeño -- pero considera esto para
un objeto con muchas propiedades. Este no es el único problema. ¿Qué pasa con las
asociaciones? Si tu objeto Gata quiere almacenar una List de gatitos? ¿También los
almacenarás? ¿Automáticamente? ¿Manualmente? ¿Qué pasa con las restricciones de
claves ajenas?
Lo mismo aplica para la carga -- asumamos que cargas un objeto Gata desde la base de
datos y que tiene una colección de Gatitos. ¿Cargarás lo gatitos también? ¿No los
cargarás ahora pero si más tarde? Si cargas los Gatitos, considerarás que cada objeto
Gatito tiene una asociación con todavía más objetos. En este caso, sería mejor cargar
todo el árbol de objetos. No cargar los gatitos tampoco será mejor -- tendrás que cargarlos
explícitamente más tarde si quieres acceder a ellos.
Como puedes ver, la diferencia objeto-relacional se amplia muy rápidametne si tienes
grandes modelos de objetos. Y hay muchas más cosas a considerar como la carga lenta,
las referencias circulares, el caché, etc. De hecho, se han realizado estudios que
demuestran que el 35% del código de una aplicación se produce para mepear datos entre la
aplicación y la base de datos.
Entonces, ¿qué puede hacer por tí un ORM? Un ORM básicamente intenta quitarte la
mayoría de esa carga de tus hombros. Con un buen ORM, sólo tienes que definir una vez la
forma en que tus clases se mapean a tablas -- que propiedad se mapea a qué columna, que
clase se mapea a qué tabla, etc. Después de esto, deberías poder hacer cosas como estas:
Con un buen ORM puedes tomar los objetos Java que usas en tu aplicación y decirle al
ORM que los persista:

orm.save(myObject);

Esto generará automáticamente todo el SQL necesario para almacenar el objeto. Un ORM
te permite cargar tus objetos igual de fácilmente:

myObject = orm.load(MyObject.class, objectId);

Un buen ORM también aportará un buen lenguaje de consultas:

List myObjects = orm.find(
"FROM MyObject object WHERE object.property = 5");

Observa que este es un ejemplo muy simple, y que tus consultas podrían ser más potentes.
Podrían expandir múltiples asociaciones, por ejemplo:

List myObjects = orm.find(
"FROM Person person
WHERE person.marriedTo.address.street LIKE %something%");

Esto probablemente se traducirá a una sentencia SQL que utiliza múltiples uniones, que
sería mucho más complicada de escribir. Un ORM también rellenará automáticamente los
objetos devueltos con sus datos, e incluso sus asociaciones (si es necesario).
Espero que ahora conozcas un poco más lo que es un ORM.

. ¿Por qué Hibernate?

Hibernate (http://www.hibernate.org) es en mi opinión el mapeador objeto-relacional de
código abierto más maduro y más completo que hay ahora. Se utiliza muy ampliamente y se
desarrollada activamente. Hibernate también soporta una de las mayores comunidades de
Open Source que he encontrado.