Nhibernate

INTRODUCCIÓN A HIBERNATE1
Septiembre 2003 Traducción: Abril 2004

Francesc Rosés Albiol
Hibernate es un entorno de trabajo que tiene como objetivo facilitar la persistencia de objetos Java en bases de datos relacionales y al mismo tiempo la consulta de estas bases de datos para obtener objetos. El objetivo de este artículo es familiarizar al lector con la filosofía utilizada en Hibernate yconseguir que sea capaz de utilizar Hibernate para desarrollar alguna aplicación. Hay, pues, un doble objetivo: “Filosófico” (observad las comillas) y práctico, Ambos objetivos van unidos. No pretendo entrar en la arquitectura de detalle usada por Hibernate ni en una discusión teórica. Partiré de mi experiencia práctica como desarrollador para ilustrar (y justificar, en parte) la filosofía deHibernate. Y si parto de la experiencia como desarrollador. He de proporcionar los medios para que un desarrollador que lea este artículo pueda, después de hacerlo, usar Hibernate. Es, pues, un objetivo de este artículo conseguir que el lector sea capaz de escribir pequeñas aplicaciones de ABM (Altas, Bajas y Modificaciones). Las posibilidades que ofrece Hibenate exceden con mucho las pretensiones deeste artículo, así que me centraré sólo en las que cubren la casuística más habitual.

HIBERNATE: UN CASAMENTERO
Cualquier persona que se dedique al desarrollo objetual se encontrará con la problemática de implementar una persistencia de objetos en un soporte relacional. El problema es que hay un divorcio total entre la estructura relacional y la objetual. Esto hace que el desarrollador opte confrecuencia por soluciones de compromiso que le hacen perder de vista el mundo objetual y la aplicación acaba siendo un batiburrillo infumable con una pseudoarquitectura objetual que hace daño a la vista. Pongamos un ejemplo. Intentemos diseñar una base de datos para una escuela. Por una parte, tendríamos la lista de personas que pertenecen a la escuela. Cada persona tiene una sola categoría:profesor, alumno, personal de administración, etc. En la escuela, hay niveles: primero de EGB, segundo de EGB, etc. Además, hay clases. Cada clase pertenece a un nivel y tiene un nombre. Así, es posible que haya tres classes de primero de EGB: A, B y C. Pero una clase no es una clase sin alumnos y profesores. Así que tendremos que asignar personas a una clase. No entraremos aquí en un diseño minuciosoni nos preocupará si una persona está en una o más clases. Así, podríamos pensar en una definición de tablas similar a esta:
CREATE TABLE CATEGORIAS ( ID INTEGER IDENTITY, CATEGORIA VARCHAR(50) NOT NULL ); 1 El presente artículo es una traducción del original en catalán escrito durante el mes de septiembre de 2003. En esta versión, no se han traducido los contenidos de las imágenes y el códigofuente para castellano aún no está disponible. Debe considerarse, pues, esta versión como draft.

1 de 30

CREATE TABLE PERSONAS ( ID INTEGER IDENTITY, NOMBRE VARCHAR(30) NOT NULL, APELLIDOS VARCHAR(100) NOT NULL, ID_CATEGORIA INTEGER NOT NULL ); ALTER TABLE PERSONAS ADD CONSTRAINT FK_P2C FOREIGN KEY ( ID_CATEGORIA ) REFERENCES CATEGORIAS ( ID ); CREATE TABLE NIVELES ( ID INTEGER IDENTITY,NIVEL VARCHAR(30) NOT NULL ); CREATE TABLE CLASE ( ID INTEGER IDENTITY, NOMBRE VARCHAR(20) NOT NULL, ID_NIVEL INTEGER NOT NULL ); ALTER TABLE CLASE ADD CONSTRAINT FK_CLASE_NIVEL FOREIGN KEY ( ID_NIVEL ) REFERENCES NIVELES ( ID ); CREATE TABLE CLASSE_PERSONAS ( ID_CLASE INTEGER NOT NULL, ID_PERSONA INTEGER NOT NULL, PRIMARY KEY (ID_CLASE,ID_PERSONA) ); ALTER TABLE CLASE_PERSONAS ADD CONSTRAINT FK_CP_CFOREIGN KEY ( ID_CLASSE ) REFERENCES CLASE ( ID ); ALTER TABLE CLASE_PERSONAS ADD CONSTRAINT FK_CP_P FOREIGN KEY ( ID_PERSONA ) REFERENCES PERSONAS ( ID );

El siguiente gráfico muestra las relaciones entre tablas:

Pero el diseño objetual con el que nos gustaría trabajar no es un calco del diseño relacional. La siguiente figura ilustra nuestro diseño objetual con un diagrama de clases UML....