JPA (JAVA PERSISTENCE API)

Ing. Marco Antonio Toscano Freire
 ::.INTRODUCCION.::
Los Enterprise Java Beans (EJB’s) en la especificación 3.0 se
fundamentan tanto en el modelo propietario como en el open source al
hacer uso de características existentes en alternativas como TopLink,
Hibernate y Spring las cuales sirvieron de influencia para el desarrollo de
la especificación de JPA.
El modelo de entidades introducido en la especificación de EJB3.0 define el
uso de JPA como mecanismo de persistencia, el cual permite persistir los
datos en un sistema de manejo de base de datos relacional utilizando los
objetos persistentes como tablas en la bdd.
JPA reemplaza a los Entity Beans en Java JEE 5 , los objetos persistentes
en esta especificación son tratados como POJOS al igual que en la mayoría
de capas de persistencia.
::.PASOS PARA CREAR UN ENTITY BEAN.::
Para crear un Entity Bean y poder utilizarlo se necesita seguir los
siguientes pasos:

● Crear un Entity Bean.- Consiste en crear el POJO que representa

la tabla de la BDD
● Mapear las clases.- Consiste en colocar las anotaciones
fundamentales de tabla, columna y id.
● Establecer y configurar las relaciones.- Consiste en colocar las
anotaciones para relacionar los POJOS.
● Crear y configurar el descriptor.- Crear el descriptor de
persistencia donde se enlazarán todas las configuraciones.
::.CONSTRUYENDO UN ENTITY BEAN.::
Para poder convertir una clase a un POJO y posteriormente a un
Entity Bean se necesita tomar en cuenta las siguientes
consideraciones:
➔ La clase debe representar a una tabla de la bdd para lo cual
debe cumplir con las características de un JavaBean (atributos
privados + métodos de acceso a esos atributos – getters and
setters) con lo cual se convertirá en un POJO (Objeto Plano).
● EL POJO debe implementar la interfaz Serializable con lo cual
se garantiza que el objeto mantenga su estado durante el
proceso de comunicación. Adicionalmente debe tener un
constructor vacio (pudiendo tener sobrecarga) que permitirá
realizar su inicialización.
::.MAPEANDO CLASES.::
Luego de que ya hemos creado los POJOS respectivos, el siguiente paso
consiste en mapear las diferentes clases a su correspondiente tabla en la
base de datos para lo cual utilizamos las siguientes anotaciones:
@Entity.- Esta anotación es la primera que se coloca en una clase JAVA,
la cual se coloca encima del la clase y permite a Glassfish conocer que
esta clase es un Entity.
@Table.- Esta anotación especifica a que tabla se va a mapear la clase,
el atributo name especifica el nombre de la tabla en la base de datos.
Esta anotación es opcional ya si no se especifica se tomará en cuenta el
nombre de la clase.
::.MAPEANDO CLASES.::
@Id.- Esta anotación indica el campo que se mapeara a la clave
primaria.
@GeneratedValue.- Esta anotación permite establecer el mecanismo
utilizada por la clave primaria para el manejo de sus datos, ya sea a
través de una secuencia, incremental etc.
@Column.- Esta anotación mapea cada campo a una columna en la
tabla, si el nombre del campo es igual al nombre de la columna en la
tabla respectiva no es necesario colocarla.
::.RELACIONES.::
Para establecer los diferentes tipos de relaciones de un Entidad con
otros Entidades utilizamos las siguientes anotaciones:
@One ToOne.- Representa una relación de uno a uno.
@ManyToOne.- Representa una relación de muchos a uno, la cual
utiliza a @OneToMany como referencia en el otro lado de la
relación.
@ManyToMany.- Representa una relación de muchos a muchos.
Cabe destacar que para realizar la configuración de las relaciones no
es necesario configurar en las dos clases que forman parte de la
relación simplemente bastará con configurar en el un lado y
referenciarla en el otro como veremos más adelante.
::.UNO A UNO - @OneToOne.::
Una relación uno a uno ocurre cuando una instancia de un Entity
tiene cero o una instancia de otro Entity.
Es necesario establecer la columna que servirá de join entre las dos
tablas para lo cual se utiliza la anotación @ JoinColumn que se ubica
luego de la anotación @OneToOne en la cual se configura a través del
atributo name cual es el nombre de la columna (base de datos) que
se utilizará para el join respectivo.
::.MUCHOS A UNO - @ManyToOne.::
Una relación mucho a uno ocurre cuando una instancia de un Entity
tiene cero o más instancias de otro Entity.
Es necesario establecer la columna que servirá de join entre las dos
tablas para lo cual se utiliza la anotación @ JoinColumn que se ubica
luego de la anotación @ManyToOne en la cual se configura a través
del atributo name cual es el nombre de la columna (base de datos)
que se utilizará para el join respectivo.
::.MUCHOS A UNO - @ManyToOne.::
Cabe destacar que en el otro lado de la relación, es decir en el otro
Entity ya no se configurará totalmente la relación sino solo se lo
referenciará utilizando la anotación OneToMany más el atributo
mappedBy donde se colocará el nombre del atributo que fue mapeado
en el otro Entity como se muestra a continuación.
::.MUCHOS A MUCHOS- @ManyToMany.::
Una relación muchos a muchos ocurre cuando una instancia de un
Entity tiene un conjunto de instancias de otro Entity y viceversa.
Este conjunto de valores está representado por collections como:
Collections, Set, List.
Las diferentes configuraciones como las columnas que se utilizan
para los joins, como las columnas referenciadas se lo especifica a
través de la anotación @JoinTable conjuntamente con los atributos
joinColumns y inverseJoinColumns.
::.MUCHOS A MUCHOS- @ManyToMany.::
De la misma que forma que en las relaciones de muchos a uno en el
otro Entity solo se lo referenciará utilizando la anotación
ManyToMany más el atributo mappedBy donde se colocará el
nombre del atributo que fue mapeado en el otro Entity como se
muestra a continuación.
::.EntityManager.::
● Provee los servicios de persistencia (las diferentes operaciones
CRUD), manejo de transacciones y el manejo del ciclo de vida de
los entities.
● El conjunto de instancias de entities manejadas dentro
EntityManager en algún tiempo es llamada Persistence
Context. No puede existir más de una instancia con el mismo
identificador persistente dentro de un Persistence Context.
● Todos los EntityManager vienen de factories de tipo
EntityManagerFactory, los cuales son los encargados de
establecer las configuraciones necesarias de un EntityManager y
encapsularla en una persistence unit.
::.EntityManager.::

Relaciones Conceptos JPA

::. Operaciones CRUD/J2SE.::
Lo primero que tenemos que hacer para trabajar con JPA en J2SE
luego de haber creado los entities es crear y configura nuestro
archivo persistence.xml .
::. Operaciones CRUD/J2SE.::
● Crear la fabrica de objetos para lo cual utilizamos el método
createEntityManagerFactory(persistenceUnit) de la
interfaz Persistence.
● Luego creamos el objeto EntityManager a través de la fábrica.
● Luego procedemos a crear las diferentes operaciones CRUD
::. Operaciones CRUD/J2SE.::

Luego procedemos a crear

las diferentes operaciones
CRUD usando los métodos
del objeto EntityManager
los cuales están dentro de
una transacción.
::.Queries.::
● En JPA un query es muy similar a un query en una base de datos
excepto que en lugar de usar SQL para especificar el criterio de
consulta, se lo hace a través de una consulta de objetos usando
un lenguaje llamado JPQL (Java Persistence Query
Language).
● Un query puede ser definido estática o dinámicamente:
✔ Un query estático es definido ya sea en una anotación o un
XML y debe incluir el criterio de búsqueda como el nombre
asignado por el usuario. Este clase de query es llamado
Named Query.
::.Queries.::
Un query dinámico puede ser proveído en tiempo de runtime
proporcionando solo el criterio de consulta JPQL, el cual puede ser más
costoso de ejecutar a causa que el proveedor de persistencia no tiene
preparado el query antes.
Para crear un query utilizamos el método createQuery(string JPQL)
del objeto EntityManager el cual dependiendo del query pasado como
string nos devolverá ya se un objeto o una colección de objetos.

No debemos olvidar que JPQL es un lenguaje de consulta basada en

objetos, por lo que los elementos del criterio de búsqueda son objetos.
::.Filtrando Resultados.::
Al igual que SQL, JPQL soporta la claúsula WHERE para realizar
las operaciones de filtrado. Debemos tomar en cuenta que las
mayoría de operadores disponibles en SQL como in, like,
between también están disponibles en JPQL.
::.Joins.::
En JPQL los joins pueden ser expresados en la cláusula FROM
usando el operador JOIN , la ventaja de esto es que el operador JOIN
puede ser expresado en términos de asociación y el motor de
queries automáticamente provee el criterio de join necesario cuando
crea el SQL.

JPQL soporta múltiples tipos de joins incluyendo inner y outer joins

entre otros.
::.Parámetros Query.::
JPQL soporta dos tipos de sintaxis para el paso o enlace de parámetros
La primera es un enlace posicional en donde los parámetros son
indicados en el query por un singo de interrogación seguido del número
del parámetro.
::.Parámetros Query.::
La segunda forma se la conoce como parámetros nombrados los
cuales son indicados en el query por el signo : seguido del nombre del
parámetro.
::.Named Queries.::
Named Queries es una forma muy poderosa de organizar y construir
los queries mejorando el rendimiento de una aplicación ya que este
tipo de queries es cargado en tiempo de ejecución gracias al uso de las
anotaciones.
Un Named Query es definido usando la anotación @NamedQuery
la cual es colocada en la definición de la clase que hace referencia al
Entity. La anotación define el nombre del query asi como el query
propiamente.

@NamedQuery(name=“Profesor.buscarTodos”, query=“SELECT
p FROM Profesor p”)
::.Named Queries.::
Se puede definir múltiples queries nombradas para lo cual utilizamos
la anotacion @NamedQueries de la siguiente forma:

@NamedQueries({@NamedQuery(name=“Profesor.findA”,
query=“conA”),
@NamedQuery(name=“Profesor.findB”, query=“conB”)})