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 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.

COMPARTE ESTE ARTÍCULO

COMPARTIR EN FACEBOOK
COMPARTIR EN TWITTER
COMPARTIR EN LINKEDIN
COMPARTIR EN WHATSAPP