Herramientas de usuario

Herramientas del sitio


unidades:01_introduccion_orm:06_intro_orm

Diferencias

Muestra las diferencias entre dos versiones de la página.


unidades:01_introduccion_orm:06_intro_orm [2023/04/07 21:26] (actual) – creado - editor externo 127.0.0.1
Línea 1: Línea 1:
 +====== 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" (( También puede escribirse como "O/RM" o "O/R mapping" )) 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 [[http://www.cefe.gva.es/webitaca/es/index.htm|Itaca]] para la consellería de educación: \\
 +El programa tendrá la clase ''Profesor'' tal y como vemos en el siguiente diagrama UML:
 +
 +<uml>
 +class Profesor 
 +Profesor : int id
 +Profesor : String nombre
 +Profesor : String ape1
 +Profesor : String ape2
 +</uml>
 +
 +Pero los objetos de la clase ''Profesor'' finalmente se deberán guardar en filas de la tabla de la base de datos llamada ''Profesor'':
 +
 +<uml>
 +class Profesor <<Table>>
 +Profesor : INTEGER id
 +Profesor : VARCHAR nombre
 +Profesor : VARCHAR ape1
 +Profesor : VARCHAR ape2
 +</uml>
 +
 +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 <javadoc jdk7>java.sql.PreparedStatement#setString(int, java.lang.String)|setString(int parameterIndex,String x)</javadoc> para pasar los datos a un <javadoc jdk7>java.sql.PreparedStatement</javadoc> 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 <javadoc jdk7>java.util.Set</javadoc> o un <javadoc jdk7>java.util.List</javadoc> 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 (( Administrador de Base de Datos )) 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 (( Realmente lo hizo para evitarse usar EJB y no JDBC )) y acabó haciendo Hibernate.
 +
 +Es decir que Hibernate es simplemente una serie de clases Java (( framework )) 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.
 +
 +<note tip>Como historia que es ésto, es totalmente mi visión de subjetiva de los acontecimientos</note>
 +
 +==== EJB ====
 +En 1999 el [[http://jcp.org|JCP]] ya empezó a estandarizar una tecnología de ORM llamada EBJ 1.0 en el [[http://www.jcp.org/en/jsr/detail?id=19|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 [[http://www.jcp.org/en/jsr/detail?id=153|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 (( El creador del Framework Spring )) , que escribió un libro titulado [[http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764558315.html|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.
 +
 +<note>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.</note>
 +
 +==== JDO ====
 +Por otro lado en el [[http://jcp.org|JCP]] también se estaba desarrollando otra especificación de ORM llamada JDO (( [[http://www.jcp.org/en/jsr/detail?id=12|JSR-12]] y [[http://www.jcp.org/en/jsr/detail?id=243|JSR-243]] )) . 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 [[wpes>Plain_Old_Java_Object|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.
 +
 +<note>
 +No es que nadie use JDO pero comparado con otras tecnologías de persistencia podríamos decir que está en un segundo plano.
 +</note>
 +==== 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. 
 +
 +<note>
 +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.
 +</note>
 +
 +==== 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 [[http://jcp.org/en/jsr/detail?id=220|JSR-220]] pero ahora tiene su propio JSR ,el [[http://jcp.org/en/jsr/detail?id=317|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.
 +
 +