César Francisco Castillo - Desarrollo de aplicaciones web con Jakarta EE

Figura 2.1 Implementaciones de JPA.

“Por su parte, el container JEE debe proveer una implementación que será la que generalmente utilizaremos, salvo que, por algún motivo, nos interese utilizar alguna otra” (Sznajdleder, 2015, pág. 107). En el caso de Glassfish y Payara, la implementación que proveen es EclipseLink. Es con la que trabajaremos en este libro.

En muchas ocasiones, los programadores sabemos para qué es y qué es lo que hace la tecnología con la que trabajamos, pero no sabemos cómo lo hace.

En esta sección intentaré desmitificar la JPA explicando sus principales componentes: su administrador de entidades (EntityManager), su unidad de persistencia (persistence unit), su contexto de persistencia (persistence context), y el archivo de configuración persistence.xml.

Para comenzar a trabajar con JPA, lo primero que necesitaremos es crear un archivo en el que podamos especificar una unidad de persistencia (persistence unit) y dentro de ella un pool de conexiones, que en la jerga se conoce como data source.

Típicamente, un archivo persistence.xml tiene el siguiente aspecto:

El EntityManager trabaja con entidades (objetos java) y es el encargado de gestionar los accesos a la base de datos mediante sus métodos find(), persist(), remove() y update(). Se lo declara de la siguiente manera:

privateEntityManager em;

Para que nuestra variable de instancia em tenga capacidad de ejecutar alguno de los métodos arriba descritos, es necesario que los objetos que se manipulen se encuentren dentro de un contexto de persistencia. ¿Cómo se logra esto? Se logra agregando la anotación @PersistenceContext en la parte superior de dicha variable. Queda de la siguiente manera:

@PersistenceContext(unitName = “unidadPersistencia”)

private EntityManager em;

El mapeo objeto-relacional es una técnica que consiste en trasladar un modelo relacional de una base de datos a un modelo orientado a objetos mediante la utilización de clases. Comencemos analizando el diagrama entidad-relación de la Figura 2.2, en el cual se describe la relación existente entre las facultades que forman parte de una universidad (esta tabla fue omitida) y las distintas carreras que en ellas se imparten.

Figura 2.2 Diagrama entidad-relación.

JPA provee una serie de anotaciones que nos permitirán realizar la representación de modelo relacional a clases Java. En la siguiente tabla vemos un conjunto reducido de ellas:

Figura 2.3 Anotaciones JPA.

Veamos cómo mapear por separado las tablas facultades y carreras utilizando las anotaciones de la sección anterior.

En la sección anterior vimos cómo mapear una entidad a una clase Java.

Ahora es el turno de analizar los distintos tipos de relaciones o asociaciones que pueden existir entre las clases y qué anotaciones utilizar para representarlas.

Si observamos el diagrama desde la perspectiva de una facultad, podemos decir que en una facultad se dictan una o más carreras. Esto significa que entre las entidades Facultad y Carrera existe una relación de uno a muchos. Para representar este vínculo, se debe agregar una lista de elementos de tipo Carrera junto a la anotación @OneToMany, como se observa en el siguiente fragmento de código:

Ahora bien, si analizamos el diagrama desde la entidad Carrera, podemos decir que varias carreras pueden pertenecer a una misma facultad, por lo que tendríamos una relación de muchos a uno. Para representar esta relación, se debe agregar una variable de instancia de tipo Facultad en la entidad Carrera junto a las anotaciones @ManyToOne y @JoinColumn para especificar que el atributo idfacultad es clave foránea, como se puede apreciar en el siguiente fragmento de código:

Tras haber realizado el mapeo, obtenemos un esquema orientado a objetos, como el que se puede apreciar en el siguiente diagrama de clases:

Figura 2.4 Diagrama de clases.

En algunas ocasiones, al diseñar el modelo de datos, nos encontraremos con tipos y subtipos de entidades que se encuentran relacionados entre sí; el tipo o supertipo agrupa características comunes y los subtipos contienen características específicas. En la Figura 2.5 Figura 2.5 Jerarquías entre tablas. Por naturaleza sabemos que tanto los alumnos como los docentes son personas, por lo que en la tabla personas tendremos los campos comunes a ellos, tales como identificador, número de documento, nombre, apellido, etc., mientras que en las otras tablas tendremos los campos específicos de cada entidad, por ejemplo, los campos sueldo y horas de cátedra para los docentes y número de legajo y fecha de ingreso para los alumnos. Para poder representar esta situación, emplearemos la herencia de clases: la tabla personas será la clase base y las tablas alumnos y docentes serán subclases de personas. Para representar la clase Persona, emplearemos la anotación @Inheritance como se observa en el siguiente fragmento de código: Por el contrario, en Alumno y Docente se debe utilizar la anotación @ PrimaryKeyJoinColumn para especificar cuál es el campo por el cual se va a establecer la relación. El siguiente fragmento de código muestra cómo quedan representadas ambas clases: se observa un ejemplo de tipo y subtipo: