Programacion EJB-Hibernate

Taller de Capacitación
Programación EJB
Framework Hibernate
Instructor: Bernal Fernández B.
(+506) 8834-9851
Copyright CCI CONSULTORES 2012 Costa Rica 1
Los modelos Relacional y OO
o  Una aplicación informática consta de dos componentes
principales que colaboran para llevar a cabo la funcionalidad
que el usuario desee. El primero de estos componentes es la
base de datos, que guarda la información necesaria para
operar la aplicación, en forma de datos en disco.
o  El segundo de estos componentes es el
programa propiamente dicho, que recupera esos
datos de la base de datos, realiza los cálculos
necesarios y presenta los resultados deseados al
usuario.
o  Para que estos dos componentes puedan
funcionar juntos deben poder comunicarse
intercambiando datos. En otras palabras, deben
ser compatibles.
Copyright CCI CONSULTORES 2012 2

Comunicación objetos–bases de datos
o  Una aplicación está formada por un programa y una base de
datos que se comunican entre sí.
o  El programa suele estar diseñado según el modelo orientado a
objetos y, por lo tanto, trabaja con datos en formato de
objetos.
o  Por el contrario, la base de datos está diseñada según el
modelo relacional y, por lo tanto, trabaja con datos en formato
de registros.
o  Esto introduce una dificultad importante, porque los dos
formatos de datos (objetos y registros) son incompatibles
entre sí. Así, cuando el programa quiere guardar o recuperar
los datos en disco (para que no se pierdan entre ejecuciones),
lo hace en forma de objetos, pues es el formato de datos que
conoce.

o  Sin embargo, la base de datos no puede guardar o recuperar
objetos, pues está diseñada para guardar o recuperar registros
(y no objetos), que es el formato de datos que ella reconoce.
o  Esto se muestra en la siguiente figura .

o  La solución más obvia a este problema es hacer que uno de los
componentes hable el idioma del otro. Es decir, que un
componente use el formato de datos del otro.
o  Así, una opción es la de que el programa esté diseñado para

tratar con datos relacionales. En esta opción, tanto el
programa como la base de datos hablan un mismo idioma: el
relacional y utilizan como formato de datos el de registro. Por
lo tanto, la comunicación es posible.


Motor de Persistencia
o  Las opciones que se basan en imponer un único modelo teórico
(un único formato de datos) a toda la aplicación padecen de
graves inconvenientes.
o  En el caso de que toda la aplicación siga el modelo relacional,
perdemos las ventajas de la orientación a objetos.
o  En el caso de que toda la aplicación siga el modelo orientado a
objetos, tenemos que las bases de datos que debemos usar
están inmaduras y tienen un bajo nivel de estandarización.
o  La opción de que el programa sea orientado a objetos y la base
de datos sea relacional, en principio, constituye la opción más
natural.
o  Por lo tanto, se debe encontrar un traductor que sepa
interpretar y comprender el idioma de cada una de las
partes.

o  En el mundo de la programación este traductor no es más que
un componente de software.
o  El motor de persistencia traduce entre los dos formatos de

datos: de registros a objetos y de objetos a registros.
o  El programa sólo ve que puede guardar objetos y recuperar

objetos, como si estuviera programado para una base de datos
orientada a objetos.
o  La base de datos sólo ve que guarda registros y recupera

registros, como si el programa estuviera dirigiéndose a ella de
forma relacional.

o  Esta solución goza de las mejores ventajas de los dos modelos.
n  Se programa con orientación a objetos, aprovechando las ventajas
de flexibilidad, mantenimiento y reusabilidad.
n  Se usa una base de datos relacional, aprovechándonos de su
madurez y su estandarización así como de las herramientas
relacionales que hay para ella.
o  Se calcula que un motor de persistencia puede reducir el código

de una aplicación en un 40%, haciéndola menos costosa de
desarrollar y simplificando la programación y su rendimiento.
o  El código que se obtiene programando de esta manera es más

limpio y sencillo y, por lo tanto, más fácil de mantener y más
robusto.


Diferencias entre JDBC y Hibernate
o  Con JDBC
Sentencias SQL directas desde el código
SQL
Clases de
BBDD
negocio
o  Con Motor de Motor de persistencia

Persistencia SQL
Clases de
negocio BBDD
Motor
Persistencia

Qué es Java Persistence API
o  Es la API de persistencia desarrollada para la plataforma Java
EE e incluida en el estándar EJB3
o  JPA es un Estándar ORM (Object Relational Mapping)
o  Disponible para JSE y JEE.

o  Definida en javax.persistence.
o  Definido según el estándar JSR 220 y JSR 317. (Contrato)
o  Es la materialización de experiencias de distintas soluciones de

ORM para java.
n  Basado en Hibernate y Java Data Object (JDO) entre otros.

Por qué usar JPA
o  Facilita la persistencia desde el punto de vista del
desarrollador.
o  Encapsula el uso de SQL, JDBC y otras tecnologías
subyacentes.
o  Incrementa la respuesta al cambio de las aplicaciones.
o  No requiere de un servidor de aplicaciones para su uso.
o  Reducción dramática en código de acceso a datos.
o  Permite concentrarse en el modelo de objeto y no en el modelo
de datos.

Capas Aplicativos

Palabras Clave
o  Entidad: Objeto con las anotaciones adecuadas para realizar la
persistencia a la BBDD.
o  POJO: Plain Old Java Object
o  Anotación: Añadir metadatos (datos descriptivos) al código
fuente.
o  JPQL: Java Persistence Query Languaje
o  NamedQuery: Consultas JPQL
o  NativeQuery: Consultas en SQL Nativo que se traducen a
objetos entidad.

Problemas de JPA
o  Incrementa el uso de recursos para el acceso a datos, ya que
agrega elementos por encima de JDBC para mejorar su eficiencia.
o  Ofrece nuevos retos en cuanto a manejo de Caches y

concurrencia.
o  Abstrae de tan alto nivel de persistencia que las optimizaciones

de DBMS no se implementan fácilmente.
o  No implementa el uso de StoredProcedures, pero por medio de

NativeQuery se puede realizar la invocación.

Implementaciones JPA
o  En el mercado hay varios proveedores para el API de JPA:
o  Hibernate.
o  OpenJPA.
o  Oracle TopLink.
o  JPOX
o  CocoBase
o  EclipseLink
o  Amber
o  Si se respeta el uso de las anotaciones estándar, la solución

puede ser interoperable entre proveedores sin cambios
traumáticos.

Versión de JPA
o  En el mercado hay dos especificaciones JPA actualmente las
cuales corresponden al JSR 220 (JPA 1.0) y JSR 317 (JPA 2.0)
o  JPA 2.0 agrega características como:

n  Colecciones de objetos embebidos.
n  Listas ordenadas.
n  Criteria API para consultas dinámicas.
n  Estandarización de query hints (extensiones que se agregan a las
consultas para poder realizar el manejo de la concurrencia sobre
los registros)
n  Estandarización de meta-datos para Data Definition Lenguaje -
DDL. (p.j que el esquema de BBDD que se genere sea similar entre
proveedores )
n  Validación, similar a lo que realiza HibernateValidator
n  Mejoras en JPQL

Arquitectura JPA
o  Relación entre los componentes principales de la Arquitectura
JPA:

Excepciones JPA
PersistenceException EntityNotFoundException
TransactionRequiredException NoResultException
OptimisticLockException NonUniqueResultException
PessimisticLockException QueryTimeoutException
LockTimeoutException
RollbackException
EntityExistsException

Definición de Entidades
o  La entidades son clases Java simples conocidas como POJOS.
o  Sus atributos pueden ser tipos primitivos (p.j. int) wrapers de tipos
primitivos (p.j. Integer), enumeraciones o otras entidades.
o  Puede contener atributos no persistentes (p.j. valores que se

deben calcular y que no interesa almacenarlos en la BBDD)
o  Se pueden heredar desde objetos entidades o no entidades.
o  Implementan la interface serializable.
o  Se pueden traspasar entre capas de la aplicación (No se requiere

un VO)

Ciclo de vida de la Entidad

Ciclo de vida de la entidad
o  Estos son métodos llamados durante el uso de una entidad en
su ciclo de vida.
Anotación Anotación
@PostLoad @PrePersist
@PostPersist @PreRemove
@PostRemove @PreUpdate
@PostUpdate

Ejemplo de Entidad
Anotación que marca el objeto
@Entity  como una entidad
 
public class Usuario implements Serializable {  
private Long idUsuario; 
 
private static final long serialVersionUID = 1L; 
  Constructor sin parámetros
siempre requerido
public Usuario() { 
super(); 
}   Marca la propiedad como el id
@Id   de la entidad
public Long getIdUsuario() { 
return this.idUsuario; 
} 
 
public void setIdUsuario(Long idUsuario) { 
this.idUsuario = idUsuario; 
}  
}
Distinciones de Entidad
o  Las entidades se configuran a base de anotaciones.
o  Estas anotaciones representan:

n  Tablas
n  Columnas
n  Relaciones
n  Multiplicidad
n  Estrategias de generación de valores (auto incrementales)
n  Querys
n  Cache
n  Herencia
n  DDL
n  CallBacks (eventos de persistencia – antes de guardar, después de
eliminar, etc…)

Ejercicio – Configuración
o  El objetivo de este ejercicio es poder configurar todas las librerias
requeridas para la implementación de un proyecto JPA –
Hibernate en el IDE Eclipse.
1.  Crear nuevo proyecto JPA

2.  Configurar la librerias de Hibernate
o  Crear una nueva “UserLibrary” denominada Hibernate
o  Inlcuya los siguientes jar dentro de la librería creada.

3.  Configurar Conexión a la Base de Datos.

5.  Estructura del Proyecto

5.  Asignar conexión a la Base de Datos en el Persistence.xml

6.  Archivo Persistence.xml

7.  Crear una JPA Entity

7.  Crear una JPA Entity

8.  Revisar el archivo de persistencia y la entidad creada
o  Comente el problema de compilación presentado inicialmente

9.  Crear un Tester para publicar la nueva entidad.
o  Incluir la siguiente instrucción en el archivo de persistencia.
<property name="hibernate.hbm2ddl.auto" value="update"/>
o  Dentro del main implementar lo siguiente:


10.  Verifique en la base de datos si la nueva entidad ha sido creada
correctamente.
11.  Cambie el nombre a la tabla por medio de la entidad y utilizando la
anotación:
n  @Table(name=”Persona")
12.  Verifique la base de datos.

Anotaciones
o  Es una forma de añadir metadatos (datos que describen otros
datos) al código fuente Java que están disponibles para la
aplicación en tiempo de ejecución.
@Entity @Column @EmbeddedId
@id
@JoinTable
@ManyToOne
@OneToOne
@Enumerated
@ManyToMany @Basic
@Table

Anotaciones de Entidad
o  Anotaciones que describen el comportamiento por defecto de
una entidad JPA, le indican al motor ORM de instrumentar la
clase como almacenable.
Anotación Descripción
@Entity Agrega la clase como
una entidad
administrada por el
motor ORM

Anotaciones de esquema Base Datos
o  Las anotaciones de esquema de base de datos ayudan a definir
el modelo de almacenamiento de los datos desde las clases
java.
o  Definen el nombre de los objetos de la base de datos que usa o
genera las entidades JPA.
@Table Define la tabla exacta que
representa la entidad
@SecondaryTable Define una tabla espejo donde se

almacenaran los datos de la
entidad

@SecondaryTables Define una colección de tablas espejo
para almacenar los datos de la entidad
@Column Define exactamente que columna de la

tabla representa la propiedad
@JoinColumn Define una columna Join para una

relación
@JoinColumns Define una colección de columnas Join
para una relación

@PrimaryKeyJoinColumns Define una colección de llaves
primarias de relación de herencia
cuando la herencia es JOIN
@PrimaryKeyJoinColumn Define la llave primaria de relación

de herencia cuando la herencia es
JOIN
@JoinTable Establece una tabla Join para una
relación
@UniqueConstraint Define un índice único sobre un
campo

Identidad
o  Anotaciones que definen la identidad de una entidad, definen
su primaryKey
@Id Define el atributo id o primary key de una
entidad
@IdClass Define los atributos de una llave
compuesta para una clase, solo
implementa los campos y en la clase que
la usa como llave primaria se referencia
como
@IdClass(com.cci.empleadoPK.class)
@EmbeddedId Define una llave compuesta tal como lo
hace @IdClass, solo que lo atributos
usados como llave primaria no se marcan
con @Id.

Identidad
@GeneratedValue Establece una columna con un valor

autoincremental o autogenerado
@SequenceGenerator Establece de donde la anotación

@GeneratedValuea va a tomar sus
secuencias, pudiendo definir
propiedades mas especificas como el
nombre de la secuencia donde se
generaran los valores auto numéricos.
@TableGenerator Es igual que @SequenceGenerator, solo
que define una tabla para los valores
auto numéricos.

Mapeos Directos
o  Estas anotaciones, definen valores directos para las columnas o
establecen propiedades adicionales sobre los atributos
marcados como Column.
@Basic Se utiliza para configurar el tipo
inicialización de las entidades
asociadas.
@Enumerated Se utiliza para marcar los atributos los
cuales se usan con enumeraciones
(Activo, Inactivo; 0,1,2)
@Temporal Se utiliza para manejar la precisión en
las fechas.

Mapeos Directos
@Lob Mapeo un campo Blob de la base

de datos
@Transient Define un campo no persistente en

la base de datos. Solo es utilizado
por Java

Mapeo de Relaciones
o  El mapeo de relaciones equivale a reflejar en las entidades las
relaciones del repositorio relacional.
@OneToOne Representa una relación uno a uno
@OneToMany Representa una relación uno a muchos,

se usa para identificar la parte única
@ManyToOne Representa una relación uno a muchos,

identifica la parte muchos

Mapeo de Relaciones
@ManyToMany Representa una relación de muchos a muchos,
se define en una Join Table.
@MapKey Las relaciones donde el resultado son muchas

entidades(como @OneToMany o @ManyToMany)
estas entidades se pueden encontrar en objetos
Set, List, Collection o Map, en este ultimo caso
se usa @MapKey para definir la llave de este
objeto llave-valor por la cual se acceden las
entidades
@MapKey(“cedula”)
Map<Long, Empleado> empleados;
En el ejemplo anterior en el map se almacenara

como llave la cédula en vez del Id.

Mapeo de Relaciones
@OrderBy Representa el campo por el cual se ordena la
relación

Composición
o  Algunos objetos no se diseñan para existir como una unidad,
sino como parte de una entidad.
@Embeddable Define una clase que hace parte de una
entidad, comparte su id pero no su
almacenamiento
@Embedded Una clase @Embeddable se puede usar

como @EmbeddedId si quiere que sea una
llave primaria compuesta y @Embedded si
se desea que esos campos sean solo unos
campos más de la clase que contiene la
anotacion @Embedded

Herencia
o  Las anotaciones de herencia, nos permiten modificar el
comportamiento de los objetos, los cuales heredan de un
objeto ya anotado.
@Inheritance Establece la configuración de herencia,
se usa en conjunto con
@DiscriminatorColumn,
@DiscriminatorValue
@DiscriminatorColumn Define como se identifican distintas
clases heredadas almacenadas en una
tabla.
@DiscriminatorValue Define el valor que tiene esta clase en
la columna @DiscriminatorColumn

Herencia
@MappedSuperclass Define una clase padre para heredar a

sus hijos las anotaciones sobre sus
campos, pero no existe como tabla en
la base de datos al no estar anotada
como @entity
@AssociationOverride Las clases padre, ya sean marcadas
como @entity o no heredan a sus
hijos las relaciones (@OneToOne,
@OneToMany), con esta anotación
podemos cambiar la definición de
esas asociaciones.
@AssociationOverrides Colección de @AssociationOverride,
para cambiar varias relaciones en la
misma clase

Herencia
@AttributeOverride Esta anotacion cambia la definicion de un
campo de un hijo de la clase padre. Por
ejemplo:
Padre @Column(name=“id”);
Hijo @AttributeOverride(name=“id”,
column=@Column(name=“identificacion”);
La columna id del padre en la clase hijo

ahora se conocera como identificacion.
@AttributeOverrides Colección de @AttributeOverride

Se usa cuando hay múltiples
@AttributeOverride

Bloque y Control de Versiones de Registro
o  Esta anotación se usa para definir manejo de concurrencia
@Version Establece un campo para el
control de versiones de una
entidad, así entre operaciones
update este valor aumenta con
el tiempo, esto así para
identificar posibles problemas de
modificación concurrente.
o  Lista de Anotaciones:
http://www.oracle.com/technetwork/middleware/ias/
toplink-jpa-annotations-096251.html

Persistencia

Persistence.xml
o  El archivo persitence.xml contiene la configuración del motor de
persistencia y define las conexiones a la base de datos y sus
entidades en unidades de trabajo llamadas persistenceUnit.

Persistence.xml
o  Configuración de la Base de Datos
Directo
Datasource

Persistence.xml
o  Configuración de la Base de Datos por medio de Datasource en el
servidor de aplicaciones (p.j: context.xml en Tomcat)

Persistance Manager
o  El mundo JPA se rige por dos objetos principales:
n  EntityManagerFactory
n  EntityManager
o  Los cuales se encargan de realizar la manipulación y búsqueda
de entidades desde:
o  El EntityManagerFactory existe uno por aplicación, es un

objeto pesado y debe abrirse y cerrarse en cada inicio de la
aplicación pero no durante su ejecución.
o  El EntityManager es un objeto liviano, el cual nos provee la

interface para gestionar las entidades.

Persistiendo una Entidad

Inicialización del Contexto de Persistencia

Operaciones con Entidades - Creación
o  EntityManager.persist(Entidad)
Entidades son simples POJOS hasta que entran en estado
managed (manejado) y luego hechos persistentes por un
EntityManager.
Si el objeto ya existe se lanzará una RunTime exception,

EntityExistsException

Operaciones con Entidades -Búsqueda
o  EntityManager.find(class, object)
El método find(…) recibe por parámetros la clase de la entidad
y valor de la llave primaria para buscar un solo objeto entidad.
Si el objeto a buscar no puede ser localizado por la clase
EntityManager, entonces este método simplemente retornará
null.

Operaciones con Entidades -Búsqueda
o  EntityManager.getReference(class, object)
Similar al método find(…), solo que en lugar de retornar null
cuando no se encuentra la entidad, éste método lanza una
EntityNotFoundException.
Otra diferencia es que algunos datos de la entidad extraída
pueden presentar carga perezosa (Lazy Loading) al ser
accedidos la primera vez.

Operaciones con Entidades - Eliminando
o  EntityManager.remove(Entidad)
Sirve para eliminar una entidad de la base de datos.
Luego de invocar este método, la entidad entrará a la fase
DETACHED del contexto de persistencia y ya no será una
entidad manejada.

Operaciones con Entidades - Actualizar
o  EntityManager.merge(Entidad)
Toma una entidad en estado DETACHED y la asocia al contexto
de persistencia del EntityManager, actualizando los datos del
objeto en la base de datos.

Operaciones con Entidades - Actualizar
Toma el objeto y lo pasa a un estado

manejado, y todos los cambios realizados al
objeto serán visibles al contexto de
persistencia del EntityManager

Operaciones con Entidades –Flush, Refresh
o  EntityManager.flush()
Sincroniza los datos de una entidad y los hace persistentes en
la base de datos.
o  EntityManager.refresh(Entidad)
Contrario al flush(), este método vuelve a cargar los datos
originales de la base de datos a la entidad.

Relaciones
o  Las entidades como abstracción de la base de datos relacional,
nos traducen estas relaciones a relaciones entre los objetos.
ü  Relaciones Unidireccionales.

ü  Relaciones Bidireccionales.
o  Las relaciones se pueden representar por medio de objetos:

§  Set
§  Map
§  List
§  Collection

Relaciones
o  Las relaciones Representadas como Colecciones pueden
establecerse en dos modos:
n  LEAZY FETCH: Obtiene únicamente los datos relacionados a la
entidad que se consulta y no sus entidades asociadas, estas
últimas se obtienen en el momento de utilizar el atributo:
n  EAGER FETCH: Contrario de Leazy.

Asociaciones
o  Existen 4 tipos de relaciones: uno a uno, uno a muchos,
muchos a uno y muchos a muchos.
Uno a Uno Uno a Muchos …
Muchos a Uno
…
… Muchos a Muchos …

Asociación @OneToOne
o  @OneToOne
Cada entidad se relaciona con una sola instancia de otra
entidad. Donde ambas se referencian por la misma llave PK.

Asociación @OneToOne

Asociación @OneToMany
o  @OneToMany
Una entidad, puedes estar asociada con varias instancias de
otras entidades.

Asociación @OneToMany

Asociación @ManyToOne
o  @ManyToOne
Múltiples instancias de una entidad pueden estar relacionadas
con una sola instancia de otra entidad.
Una ciudad solo puede estar en un país, pero un país puede tener varias ciudades.

Asociación @ManyToOne

Asociación @ManyToMany
o  @ManyToMany
Varias instancias de una entidad pueden relacionarse con
múltiples instancias de otras entidades.

Asociación @ManyToMany

Relaciones y Generación de DDL

Objetos embebidos
Son campos comunes entre entidades que se pueden repetir pero no

tienen una relación tan estrecha como para realizar una herencia.
Son relaciones Lógicas y no físicas

Herencia
o  El uso de entidades anotadas posibilita la herencia de los
objetos persistentes.
o  No solo las clases anotadas se pueden heredar.

Estrategias de Herencia
Single Table
• Todas la entidades heredadas
se almacenan en la misma
tabla de la base de datos
Joined
• Los atributos compartidos se
almacenan en una tabla, los
atributos particulares se
almacenan en otra tabla.
Table per class

• Cada clase se almacena en
una tabla separada

Estrategias de identidad
o  Simple
n  @Id: Un campo marcado con @Id será la llave primaria de la entidad,
pero si no tiene otra anotación, este valor deberá ser ingresado antes
de almacenar
n  @GeneratedValue: se usa en conjunto con @Id, así los valores para
la llave primaria se generaran automáticamente y no se deberá
ingresar antes de almacenar
o  Definida por el usuario
n  @EmbeddedId: la clase usada debe marcarse como @Embeddable y
se usa para definir entidades con llaves compuestas
n  @IdClass: funciona igual que @EmbeddedId, solo que ya la clase
usada como llave compuesta no hace parte del objeto que tiene llave
compuesta, solamente se usara @IdClass(llaveCompuesta.class) y
en el cuerpo de la clase entidad, se marcaran variables idénticas a las
seleccionadas como llave compuesta por la clase usada como @IdClass

Estrategias de identidad

Diagrama de Ejercicio.

Java Persistence Query Languaje
o  Las consultas JPQL son muy similares a SQL
o  Soportan consultas SELECT, DELETE, UPDATE
o  Soporta SELECT con GROUP BY, HAVING, JOIN, LEFT JOIN,
RIGTH JOIN, IN

Palabras Reservadas JPQL

Funciones Predefinidas de JPQL

Querys
o  Las consultas en JPA se expresan en JPQL Query o Native
Query, en ambos tipos existen consultas persistentes y
continuas llamadas Named Query.
n  Named Query : Consultas comunes escritas en JPQL

Querys
o  Las consultas en JPA se expresan en JPQL Query o Native
Query, en ambos tipos existen consultas persistentes y
continuas llamadas Named Query.
n  Named Query : Consultas comunes escritas en JPQL

Querys
n  Invocación de Named Query:

Querys
n  Named Native Query : Consultas comunes expresadas en SQL
especifico del motor de base de datos

Querys
n  Invocación de Native Query:

Querys
n  Las Native Querys pueden ser complejas y cambiar el nombre de
las columnas dependiendo de su uso.
n  @SqlResultSetMapping mapea los resultados de la consulta a

atributos de las entidades resultantes de la búsqueda.

Criteria API
o  Criteria API nos permite generar complejas consultas sin la
necesidad de construirlas a través de condiciones o valores
tomados directamente desde la interface de usuario.
o  Para realizar búsquedas complejas, Criteria API se puede
apoyar sobre las clases MetaModels.

Criteria API

Ejemplo Criteria API

Ejemplo Criteria API

Ejemplo Criteria API (Logs Hibernate)

JPA VALIDATOR
o  JPA Validator nos permite agregar validaciones a los setters de
nuestras entidades, evitando así errores de datos comunes.
o  Esta validaciones están disponibles siempre y cuando se

disponga de la librería javaxi.validation
o  Esta librería puede ser implementada con HibernateValidator

Hibernate Validator
o  Hibernate Validator es la implementación para el JSR 303
(Bean Validation)
o  Define el uso de anotaciones o archivos XML como fuente de

validaciones para los beans (entidades JPA).
o  Hibernate Validator se puede usar en cualquier clase, no solo

en entidades JPA, pero es especialmente útil en estas ultimas.
o  Se debe contar con las librerías:

n  Validation-api
n  Hibernate-validator-processor

Implementando validaciones
o  Las validaciones se pueden hacer en 3 niveles:
n  Validaciones por campo: esta validaciones se establecen
directamente en la variable, esto hace que hibernate validator
invoque directamente las variables y no invoque su getter y setter
n  Validaciones por propiedad: estas validaciones se establecen

sobre las propiedades (getter y setter) de la clase, cuando esto
sucede, hibernate validator, usa el getter y setter de la propiedad
para obtener acceso al valor a validar. Esto es útil cuando por
algún motivo en el getter o setter modificamos el valor de una
variables.
n  Validaciones a nivel de clase: Las validaciones a nivel de clase

son útiles cuando estas contienen clases que deben ser validadas
en su interior o cuando se desea realizar validaciones
personalizadas sobre las clases

Validaciones
o  Las Validaciones son heredables entre clases.
o  Las validaciones agregadas a una clase hijo son sumadas a las
de su padre (no sustituyen las heredada)
o  Las validaciones pueden ser recursivas y se pueden realizar

sobre objetos colección (Collection, List, Set, Map)

JPA VALIDATOR

JPA VALIDATOR
@DecimalMax El valor de la variables debe ser
menor o igual a el valor de la
anotacion
@DecimalMin El valor de la variables debe ser
mayor o igual a el valor de la
anotacion
@Digits(integer=, fraction=) El valor de la variable anotada

debes tener una parte decimal y
otra entera
@Future El valor de la fecha debe ser en el
futuro

JPA VALIDATOR
@Max Verifica si el valor de la variables
anotada es menor o igual a el valor
proveído por la anotación
@Min Verifica si el valor de la variables
anotada es mayor o igual a el valor
proveído por la anotación
@Size(min=, max=) Verifica si el elemento anotado esta

entre el tamaño proveído por la
anotación

JPA VALIDATOR
@Null La propiedad debe ser null
@NotNull La propiedad no debe ser null
@AssertFalse La propiedad debe ser false
@AssertTrue La propiedad debe ser true
@Past La Fecha debe ser en el pasado
@Pattern(regex=, flag=) Debe cumplir con expresión regular
@Valid Valida que los objetos asociados
cumplan con sus validaciones

Validaciones

Validaciones
o  Las validaciones pueden ser a nivel de clase, esta validación
permite validar la cantidad de pasajeros que contiene la
variables passangers
Creación de Constraints (PassangersCount)

http://docs.jboss.org/hibernate/validator/4.0.1/reference/en/html/validator-
usingvalidator.html
Validaciones sobre colecciones
o  Las validaciones pueden ser recursivas a los objetos
contenidos dentro de nuestra clase, esa tarea se facilita con
la anotación @Valid

Validando
o  Si se usa JPA y las librerías de Hibernate Validator, el motor
JPA se encargará de llamar las validaciones antes de persistir
en la base de datos.
o  Si se usa fuera de JPA se debe llamar manualmente las

validaciones y verificar sus resultados:
ClassValidator<Book> validator = new ClassValidator<Book>(Car.class);

InvalidValue[] invalidValues = validator.getInvalidValues(carInstance);

Diagrama de Ejercicio.

Diagrama de Ejercicio - Complementario

Programacion EJB-Hibernate

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Programacion EJB-Hibernate

Cargado por

Copyright:

Formatos disponibles

Taller de Capacitación

Copyright CCI CONSULTORES 2012 2

Copyright CCI CONSULTORES 2012 3

Copyright CCI CONSULTORES 2012 4

o Así, una opción es la de que el programa esté diseñado para

Copyright CCI CONSULTORES 2012 5

Copyright CCI CONSULTORES 2012 6

Copyright CCI CONSULTORES 2012 7

o El motor de persistencia traduce entre los dos formatos de

o El programa sólo ve que puede guardar objetos y recuperar

o La base de datos sólo ve que guarda registros y recupera

Copyright CCI CONSULTORES 2012 8

o Se calcula que un motor de persistencia puede reducir el código

o El código que se obtiene programando de esta manera es más

Copyright CCI CONSULTORES 2012 9

Copyright CCI CONSULTORES 2012 10

o Con Motor de Motor de persistencia

Copyright CCI CONSULTORES 2012 11

o JPA es un Estándar ORM (Object Relational Mapping)

o Disponible para JSE y JEE.

o Es la materialización de experiencias de distintas soluciones de

Copyright CCI CONSULTORES 2012 12

Copyright CCI CONSULTORES 2012 13

Copyright CCI CONSULTORES 2012 14

Copyright CCI CONSULTORES 2012 15

o Ofrece nuevos retos en cuanto a manejo de Caches y

o Abstrae de tan alto nivel de persistencia que las optimizaciones

o No implementa el uso de StoredProcedures, pero por medio de

Copyright CCI CONSULTORES 2012 16

o Si se respeta el uso de las anotaciones estándar, la solución

Copyright CCI CONSULTORES 2012 17

o JPA 2.0 agrega características como:

Copyright CCI CONSULTORES 2012 18

Copyright CCI CONSULTORES 2012 19

Copyright CCI CONSULTORES 2012 20

o Puede contener atributos no persistentes (p.j. valores que se

o Se pueden heredar desde objetos entidades o no entidades.

o Implementan la interface serializable.

o Se pueden traspasar entre capas de la aplicación (No se requiere

Copyright CCI CONSULTORES 2012 21

Copyright CCI CONSULTORES 2012 22

Copyright CCI CONSULTORES 2012 23

o Estas anotaciones representan:

Copyright CCI CONSULTORES 2012 25

Copyright CCI CONSULTORES 2012 26

Copyright CCI CONSULTORES 2012 27

Copyright CCI CONSULTORES 2012 28

Copyright CCI CONSULTORES 2012 29

Copyright CCI CONSULTORES 2012 30

Copyright CCI CONSULTORES 2012 31

Copyright CCI CONSULTORES 2012 32

Copyright CCI CONSULTORES 2012 33

Copyright CCI CONSULTORES 2012 34

<property name="hibernate.hbm2ddl.auto" value="update"/>

o Dentro del main implementar lo siguiente:

Copyright CCI CONSULTORES 2012 35

Copyright CCI CONSULTORES 2012 36

Copyright CCI CONSULTORES 2012 37

@Entity @Column @EmbeddedId

Copyright CCI CONSULTORES 2012 38

Copyright CCI CONSULTORES 2012 39

@SecondaryTable Define una tabla espejo donde se

Copyright CCI CONSULTORES 2012 40

@Column Define exactamente que columna de la

o  Así, una opción es la de que el programa esté diseñado para

o  El motor de persistencia traduce entre los dos formatos de

o  El programa sólo ve que puede guardar objetos y recuperar

o  La base de datos sólo ve que guarda registros y recupera

o  Se calcula que un motor de persistencia puede reducir el código

o  El código que se obtiene programando de esta manera es más

o  Con Motor de Motor de persistencia

o  JPA es un Estándar ORM (Object Relational Mapping)

o  Disponible para JSE y JEE.

o  Es la materialización de experiencias de distintas soluciones de

o  Ofrece nuevos retos en cuanto a manejo de Caches y

o  Abstrae de tan alto nivel de persistencia que las optimizaciones

o  No implementa el uso de StoredProcedures, pero por medio de

o  Si se respeta el uso de las anotaciones estándar, la solución

o  JPA 2.0 agrega características como:

o  Puede contener atributos no persistentes (p.j. valores que se

o  Se pueden heredar desde objetos entidades o no entidades.

o  Implementan la interface serializable.

o  Se pueden traspasar entre capas de la aplicación (No se requiere

o  Estas anotaciones representan:

o  Dentro del main implementar lo siguiente:

o  El EntityManagerFactory existe uno por aplicación, es un

o  El EntityManager es un objeto liviano, el cual nos provee la

ü  Relaciones Unidireccionales.

o  Las relaciones se pueden representar por medio de objetos:

n  EAGER FETCH: Contrario de Leazy.