Introducción a los ORM

En este tema vamos a empezar a explicar qué ese un ORM e Hibernate , pero empecemos con los ORM.

Las siglas ORM significan “Object-Relational mapping” 1) y en castellano es “Mapeo Objeto-Relacional”. El ORM es simplemente el código que escribimos para guardar el valor de nuestras clases en una base de datos relacional. Simplemente éso.

Es decir, es un framework de persistencia de nuestros datos a una base de datos.

Veamos un ejemplo en el que suponemos que estamos desarrollando el programa Itaca para la consellería de educación:
El programa tendrá la clase Profesor tal y como vemos en el siguiente diagrama UML:

PlantUML Graph

Pero los objetos de la clase Profesor finalmente se deberán guardar en filas de la tabla de la base de datos llamada Profesor:

PlantUML Graph

El código Java que, dado un objeto Profesor , genera una fila en la tabla Profesor o la borra o la actualiza, etc, es un ORM. Así de sencillo.

Ahora te estarás preguntando, ¿y para éso necesito un curso entero del CEFIRE? ¡Si yo llevo años haciendo eso con JDBC!.
Si pero:

  • ¿Cuántas veces has llamado a setString(int parameterIndex,String x) para pasar los datos a un java.sql.PreparedStatement y poder almacenarlos en la base de datos?
    Demasiadas veces y ¡ estoy harto de hacerlo!.
  • ¿Y qué hay del código de JDBC cuando la clase Profesor incluye un java.util.Set o un java.util.List o simplemente herencia de otras clases.?
    Ese código no debe tocarse mientras no se deje la empresa ya que se corre el peligro de que nada vuelva a funcionar.
  • ¿Y de hacer las validaciones antes de guardarlo?¿No estas harto de comprobar que la propiedad nombre no está vacía?
    La próxima vez que compruebe que un String no es null y que tras hacer un trim() aún quedan caracteres me rapo el pelo y me hago budista.
  • ¿Recuerdas el día en el que el DBA 2) te pidió que cambiaras el nombre de varias columnas de la base de datos?
    Estuve semanas revisando el código para estar seguro de que no me había dejado ninguna línea sin cambiar. Al volver a casa mi hijo ya no me conocía.

Dejando a parte esta pequeña broma, usar JDBC directamente tiene muchos problemas. Lo normal es que para evitar toda esta repetición de código los programadores empecemos a hacernos nuestras utilidades que nos ahorran mucho esfuerzo. Estas utilidades son el principio de un ORM. Gavin King pensó lo mismo 3) y acabó haciendo Hibernate.

Es decir que Hibernate es simplemente una serie de clases Java 4) que nos ayudaran a insertar, leer, actualizar borrar nuestros objetos en la base de datos.

Historia de los ORM en Java

En la comunidad Java se ha tenido claro que al programar es necesario usar un ORM y por ello se han creado gran cantidad de ORM. Pasemos a hacer un repaso de la historia de los ORM en Java.

Como historia que es ésto, es totalmente mi visión de subjetiva de los acontecimientos

EJB

En 1999 el JCP ya empezó a estandarizar una tecnología de ORM llamada EBJ 1.0 en el JSR-19. Como siempre pasa con las versiones “1.0” y con ser una nueva tecnología , fue un verdadero fracaso. Pero Sun y los grandes vendedores de Servidores de Aplicaciones en Java no pensaban desistir en su empeño de usar los EJB. Los EJB eran una tecnología de ORM que sólo podía usarse dentro de un Servidor de aplicaciones de Java EE por lo que obligaría a los programadores a que usáramos sus caros Servidores de Aplicaciones.

Volvieron al ataque con EJB 2.0 en el año 2001 y con EJB 2.1 en el año 2003 con el JSR-153 pero siguió siendo un fracaso. Realmente no fue un fracaso ya que por aquella época en libros, revistas , blogs ,etc, no paraban de explicar que para hacer una aplicación empresarial con Java era necesario usar EJBs. Cuántos pobres Jefes de Proyecto cayeron en la trampa y acabaron con proyectos fracasados por culpa de los EJB.
Un caso curioso fue el de Rod Johnson 5) , que escribió un libro titulado J2EE Development without EJB. Fue la primera vez que vi un título de un libro que en vez de hablar de la tecnología que se debe usar, habla de tecnología que NO se debe usar. Podemos imaginar cómo debía estar el mundo Java para necesitar un libro así. Yo personalmente era uno de los que necesité ese libro.

Realmente los EJB no eran tan inútiles como los he pintado pero no había tantos proyectos en los que fuera la tecnología correcta. Desde mi punto de vista su mayor error fue intentar popularizarlos para que todo el mundo los usara.Aunque quizás dicho error fuera intencionado por parte de los vendedores de Servidores de Aplicaciones para vender sus productos.

JDO

Por otro lado en el JCP también se estaba desarrollando otra especificación de ORM llamada JDO 6) . JDO tenía varias ventanas respecto a los EJB:

  • Las clases a persistir (por ejemplo la clase Profesor ) no tenían que heredar de ninguna clase ni implementar ningún interfaz, lo que hacía trasparente la persistencia a la base de datos. Es decir, que sean POJOs
  • No necesitaba de un Servidor de Aplicaciones para funcionar
  • Podía persistir a otro tipo de repositorios de datos que no fueran bases de datos relacionales

Con todo ello JDO era superior a los EJB, ¿qué pasó? Que JDO nunca ha tenido el apoyo de las grandes empresas ni ha sido cool como pudieron ser los EJB en su momento. Así que JDO es una tecnología que nadie usa.

No es que nadie use JDO pero comparado con otras tecnologías de persistencia podríamos decir que está en un segundo plano.

Hibernate

Hasta ahora hemos visto las tecnología de EJB y JDO. Estas tecnologías son únicamente las especificaciones y necesitan de alguien que haga las implementaciones de dichas especificaciones.

En 2001 Gavin King creó Hibernate. Harto de los EJB, no se basó en ningún JSR ni ninguna especificación, simplemente creó un framework de ORM y la historia ha querido de Hibernate haya sido el ORM que mas éxito ha tenido.

¿Cuál ha sido el éxito de Hibernate? Mi opinión es la siguiente:

  • No depende de estándares, lo que hace que pueda añadir funcionalidades mas rápidamente.
  • Al igual que JDO no es necesario implementar interfaces o heredar de clases.
  • Realiza sólo una cosa y la hace bien: Sólo se puede persistir a bases de datos relacionales, a diferencia de JDO que permite otros tipo de repositorios.

¿Pero cuál es, entonces, la desventaja de Hibernate? La principal desventaja es que al no haber una especificación detrás de él , si usas Hibernate ya no puedes cambiar de framework de persistencia tan fácilmente como podrías usando JDO o EJB.

Realmente creo que ésto es un poco un mito. Aunque uses EJB o JDO cambiar de implementación no debe ser tan sencillo como nos lo quieren hacer ver.

JPA

El último que ha aparecido en esta historia es JPA . JPA es una especificación del JCP al igual que JDO y EJB. Inicialmente JPA se desarrolló en el mismo JRS que EJB 3.0 JSR-220 pero ahora tiene su propio JSR ,el JSR-317.

¿Y cómo encaja JPA en todo ésto?
Mi opinión personal es que no entiendo para qué crear JPA existiendo ya JDO. Sin embargo, JPA está teniendo el éxito que JDO nunca tuvo así que, siendo pragmáticos , JPA es el estándar de persistencia en Java y para aupar más aún a JPA ,Hibernate implementa la especificación de JPA pero no la de JDO. Así que ahora podemos usar Hibernate siguiendo un estándar por lo que podríamos cambiar de Hibernate a otra implementación sin problemas.

Hibernate

Después de dar un repaso a todas las tecnologías de persistencia, ¿Por qué un curso de Hibernate en vez de un curso de JPA? Realmente este curso trata de Hibernate e Hibernate con JPA con lo que vamos a tener lo mejor de ambos mundos.

Para hacer la persistencia de nuestros objetos Java a la base de datos hay que indicar cómo se debe realizar dicha persistencia. Para ello hay dos métodos:

  • Ficheros XML
  • Anotaciones en el código.

Las anotaciones que tiene Hibernate son actualmente las del estándar de JPA. De esa forma al ver las anotaciones de hibernate estaremos viendo las de JPA.Cuando veamos los ficheros XML usaremos los ficheros propietarios de Hibernate, así también veremos cómo funciona realmente Hibernate.

En cuanto al API de Java , vamos a ver únicamente el API de Hibernate.

¿Y por qué no dar sólo JPA sobre Hibernate ?
JPA sigue siendo un estándar de JCP , lo que conlleva un proceso lento de nuevas versiones y funcionalidades. Usando Hibernate directamente tendremos acceso a las funcionalidades específicas de Hibernate que no están cubiertas en el estándar de JPA y tampoco hay que ser tan estricto. Hibernate ha funcionado con éxito muchos años en Java sin necesidad de JPA, así que no vamos a perder ahora todas las ventajas de ofrece Hibernate frente a JPA.

Resumiendo , éste va a ser un curso de Hibernate en el que muchas de las cosas que expliquemos será usando el estándar de JPA.

1) También puede escribirse como “O/RM” o “O/R mapping”
2) Administrador de Base de Datos
3) Realmente lo hizo para evitarse usar EJB y no JDBC
4) framework
5) El creador del Framework Spring
unidades/01_introduccion_orm/06_intro_orm.txt · Última modificación: 2016/07/03 20:35 (editor externo)
Ir hasta arriba
CC Attribution-Noncommercial-Share Alike 3.0 Unported
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0