View
1.500
Download
9
Category
Preview:
DESCRIPTION
Esta presentación les ayudará a entender como JPA maneja las relaciones de clases y las llaves primarias compuestas.Además de como crear validadores y conversores.
Citation preview
Aurelio Martín Obando Távaraaot@upnorte.edu.pe
proyectos ii
INTRODUCCIÓN A JEE5 – PARTE II
Enalteciendo Los Temas
2Beans de Sesión
3Converter y
Validator
1 1Entidades
AGENDA EntidadesBeans de SesiónConverter y ValidatorResumen
Clase 05
1
2 CONTENIDO
Una entidad es un objeto del dominio de persistencia, pero mucho mas ligero. Típicamente una entidad representa una tabla de un modelo de datos relacional, en donde cada instancia de la entidad es una fila en dicha tabla.
JPA brinda soporte para facilitar la construcción y mantenimiento de las relaciones entre clases, su cardinalidad: @OneToOne, @OneToMany, @ManyToOne, @ManyToMany y la navegabilidad: Bidireccional y Unidireccional.
Y finalmente, brinda gran facilidad al momento de mapear herencias o especializaciones entre objetos.
ENTIDADES
Toda entidad debe tener una llave primaria
Puede mapearse a una (llave primaria simple) o más (llave primaria compuesta) propiedades
Consiste de múltiples llaves primarias simples
LAVES PRIMARIAS COMPUESTAS
Llav
es P
rimar
ias
Com
pues
tas Consiste de múltiples llaves primarias
Puede ser representada por un clase “Primary Key” que…
debe ser Serializablepublic class MowerPK implements java.io.Serializable {
debe tener un constructor público sin paso de parámetros
public MowerPK() { … }debe implementar los métodos equals() y hashCode() public int hashCode() { ... }
public boolean equals(Object obj) { ... }
Usa
ndo
una
Clas
e Pr
imar
y Ke
y co
mo
un Id
Clas
sNo es usada internamente por clases persistentes
Usado por el Entity Manager
Ejemplo de esquema de base de datos
create table MOWER (make varchar(255) not null, model varchar(255) not null, size integer not null, primary key (make, model)
)
Ejem
plo
de C
lase
Com
pues
ta
PKpackage ejava.examples.orm.core;
import java.io.Serializable;public class MowerPK implements Serializable { private static final long serialVersionUID = 1L; private String make; private String model; public MowerPK() { … } public MowerPK(String make, String model) { this.make = make; this.model = model; } public static long getSerialVersionUID() { return serialVersionUID; } public String getMake() { return make; } private void setMake(String make) { this.make = make; }…
Ejem
plo
de C
lase
Com
pues
ta
PK (C
ont.)
… public String getModel() { return model; } private void setModel(String model) { this.model = model; } public int hashCode() { return make.hashCode() + model.hashCode(); } public boolean equals(Object obj) { try { if (this == obj) return true; return make.equals(((MowerPK)obj).getMake()) && model.equals(((MowerPK)obj).getModel()); } catch (Throwable ignored) { return false; } } public String toString() { return super.toString() + ", make=" + make + ", model=" + model; }}
Ejem
plo
de u
so d
e un
IdCl
ass package ejava.examples.orm.core.annotated;
import java.io.Serializable;import javax.persistence.*;import ejava.examples.orm.core.MowerPK;
@Entity@Table(name="MOWER")@IdClass(MowerPK.class)public class Mower implements Serializable { private static final long serialVersionUID = 1L; private String make; private String model; private int size; public Mower() { … } public Mower(String make, String model) { this.make = make; this.model = model; }
…
Ejem
plo
de u
so d
e un
IdCl
ass
(Con
t.)
… @Id @Column(nullable=false, updatable=false) public String getMake() { return make; } private void setMake(String make) { this.make = make; } @Id @Column(nullable=false, updatable=false) public String getModel() { return model; } private void setModel(String model) { this.model = model; } public int getSize() { return size; } public void setSize(int size) { this.size = size; }}
Usa
ndo
un c
lase
Prim
ary
Key
com
o un
Em
bedd
edId
Esquema de base de datos
create table NAPSACK (NAPSACK_MAKE varchar(255) not null, NAPSACK_MODEL varchar(255) not null, size integer not null, primary key (NAPSACK_MAKE, NAPSACK_MODEL)
)
Ejem
plo
de E
mbe
dded
Idpackage ejava.examples.orm.core.annotated;
import java.io.Serializable;import javax.persistence.*;
@Embeddablepublic class NapsackPK implements Serializable { private static final long serialVersionUID = 1L; private String make; private String model; public NapsackPK() { … } public NapsackPK(String make, String model) { this.make = make; this.model = model; }
@Column(name="NAPSACK_MAKE") public String getMake() { return make; } public void setMake(String make) { this.make = make; }
…
Ejem
plo
de E
mbe
dded
Id
(Con
t.)
@Column(name="NAPSACK_MODEL") public String getModel() { return model; } public void setModel(String model) { this.model = model; }
public int hashCode() { return make.hashCode() + model.hashCode(); }
public boolean equals(Object obj) { try { if (this == obj) return true; return make.equals(((NapsackPK)obj).getMake()) && model.equals(((NapsackPK)obj).getModel()); } catch (Throwable ignored) { //catch NP & Cast Exceptions return false; } } public String toString() { return super.toString() + ", make=" + make + ", model=" + model; }}
Ejem
plo
de u
so d
e Em
bedd
edId
usan
do A
nota
cion
espackage ejava.examples.orm.core.annotated;
import java.io.Serializable;import javax.persistence.*;
@Entity@Table(name="NAPSACK")public class Napsack implements Serializable { private static final long serialVersionUID = 1L; private NapsackPK pk; private int size; public Napsack() {} public Napsack(String make, String model) { this.pk = new NapsackPK(make, model); } @EmbeddedId public NapsackPK getPk() { return pk; } public void setPk(NapsackPK pk) { this.pk = pk; } …}
JPA reconoce y mapea las relaciones en el modelo de datos relacional y lo translada a las clases en el modelo de dominio
De este modo, las cardinalidades como Uno-a-Uno, Muchos-a-Uno, Uno-a-Muchos y Muchos-a-Muchos existen como anotaciones en el marco de trabajo JPA
Estas anotaciones también son susceptible a cierta optimización de acuerdo a ciertas características que veremos a continuación
MAPEO DE OBJETOS Y RELACIONES
One-To-One (Uno-a-Uno)
One
ToO
neUni-direccional
Bi-direccional
One
ToO
ne
Uni-Direcciona
l
•solo una clase (“owner”) conoce la relación•usa
@OneToOne•esta clase
define el mapeo a la base de datos•podría usar
@JoinColumn o @JoinTable
Bi-Direcciona
l
•ambas clases conocen la relación•usan @OneToOne
•una clase (“owner”) define el mapeo a la base de datos•podría usar
@JoinColumn o @JoinTable
•la otra clase (“inverse side”) señala la propiedad de la clase dueño que define la relación•usa
@OneToOne(mappedBy=”remote property”)
Anot
ació
n @
One
ToO
nepublic interface OneToOne extends ... {
Class targetEntity() default void.classclase entidad a la que está relacionadausualmente se determina por el tipo de la propiedad
CascadeType[] cascade() default {}define que operaciones de persistencia se realizan en modo cascada sobre el objeto relacionado
FetchType fetch() default EAGERdefine el modo de carga del objeto relacionado
boolean optional() default truedefine si wl valor de la relación puede ser nula o no
String mappedBy() default “”usado solo en relaciones bidireccionales en el lado inverso de la relaciónseñala la propiedad remota en la clase dueña de la relación que define el mapeo a la base de datos
Anot
ació
n @
Join
Colu
mns
public interface JoinColumns extends ... {
public abstract JoinColumn[] value();define un arreglo de claves foráneas que son parte de una llave primaria compuesta
Example Usage
@OneToOne@JoinColumns({
@JoinColumn(...),@JoinColumn(...)
})
Many-To-One (Muchos-a-Uno)
Man
yToO
neUni-direccional
Bi-direccional
Man
yToO
ne
Uni-Direcciona
l
•El lado “many “ es la unica clase (“owner”) que conoce la relación•usa
@ManyToOne•Esta clase
define el mapeo a la base de datos•Podría usar
@JoinColumn o @JoinTable
Bi-Direcciona
l
•Se requiere que el lado “many” sea el dueño de la relación
•El lado “one” (“inverse side”) señala la propiedad de la clase dueña que define la relación•Podría usar
@OneToMany(mappedBy=”remote property”)
Anot
ació
n @
Man
yToO
nepublic interface ManyToOne extends ... {
Class targetEntity() default void.classclase entidad a la que está relacionadausualmente se determina por el tipo de la propiedad
CascadeType[] cascade() default {}define que operaciones de persistencia se realizan en modo cascada sobre el objeto relacionado
FetchType fetch() default EAGERdefine el modo de carga del objeto relacionado
boolean optional() default truedefine si wl valor de la relación puede ser nula o no
Anot
ació
n @
One
ToM
any
public interface OneToMany extends ... {
Class targetEntity() default void.classclase entidad a la que está relacionadausualmente se determina por el tipo de la propiedad
CascadeType[] cascade() default {}define que operaciones de persistencia se realizan en modo cascada sobre el objeto relacionado
FetchType fetch() default EAGERdefine el modo de carga del objeto relacionado
String mappedBy() default “”usado solo en relaciones bidireccionales en el lado inverso de la relaciónseñala la propiedad remota en la clase dueña de la relación que define el mapeo a la base de datos
Mod
ifica
ndo
una
lista
de
obje
tos
Incorrecto
•No reemplazar la colección de un objeto administrado con otra de un objeto no administrado
•Collection<Checkout> newCheckouts = ...
•borrower.setCheckouts(newCheckouts); //ERROR!
Correcto
•Actualizar la colección existente dentro del objeto administrado
•Collection<Checkout> newCheckouts = ...
•borrower.getCheckouts().add(newCheckouts);
One-To-Many (Uno-a-Muchos)
One
ToM
any
Uni-direccional
One
ToM
any
Uni-Direccional
• El lado “one“ es la unica clase (“owner”) que conoce la relación• usa @OneToMany
• Esta clase define el mapeo a la base de datos usando un Join (o “link”) table• Debe usar @JoinTable
Bi-Direccional
• Lo mismo que el caso bidireccional de ManyToOne
Link
/Joi
n Ta
ble
Anot
ació
n @
Join
Tabl
epublic interface JoinTable extends ... {
muy similar a la anotación @Table
String name() default “”nombre de la tabla para la tabla “join”
String catalog() default “”nombre de la base de datos
String schema() default “”nombre del esquema
JoinColumn[] joinColumns() default {}arreglo de columnas que definen la clave foranea a este
objetoJoinColumn[] inverseJoinColumns() default {}
arreglo de columnas que definen la llave foráneo al objeto relacionado
UniqueConstraint[] uniqueConstraints()
Many-To-Many (Muchos-a-Muchos)
Man
yToM
any
Uni-direccional
Bi-direccional
Man
yToM
any
Uni-Direccional
• Una clase (“owner”) conoce la relación• usa @ManyToMany
• Esta clase define el mapeo a la base de datos usando un Join (o “link”) table• usa @JoinTable
Bi-Direccional
• Ambas clases conocen la relación• Usan @ManyToMany
• El dueño de la relación define el mapeo a la base de datos• Usa @JoinTable
• El lado inverso señala la propiedad de la clase dueña que define el mapeo a la base de datos• Usa
@ManyToMany(mappedBy=«remote property»)
Anot
ació
n @
Man
yToM
any public interface ManyToMany extends ... {
Class targetEntity() default void.classclase entidad a la que está relacionadausualmente se determina por el tipo de la propiedad
CascadeType[] cascade() default {}define que operaciones de persistencia se realizan en modo cascada sobre el objeto relacionado
FetchType fetch() default EAGERdefine el modo de carga del objeto relacionado
String mappedBy() default “”usado solo en relaciones bidireccionales en el lado inverso de la relaciónseñala la propiedad remota en la clase dueña de la relación que define el mapeo a la base de datos
ALL- combinación de todos los tiposPERSIST- objetos relacionados son automáticamente administrados y serán persistentes en la base de datos cuando han sido relacionado a este objetoREMOVE- objetos relacionados son eliminados de la base de datos cuando este objeto es eliminadoREFRESH- objetos relacionados traerán su “estado” de la base de datos cuando este objeto es “refrescado”MERGE- objetos relacionados actualizarán su “estado” en la base de datos cuando este objeto es actualizado
TIPOS DE CASCADA
JPA contiene anotaciones que permiten mapear herencia entre clases a la base de datos.
Existen algunas estrategias para realizar esto:- Tabla Única- Tabla por Clase Concreta- Tabla por Clase (Join)
MAPEO DE HERENCIA DE OBJETOS
Estr
ateg
ia d
e H
eren
cia:
Tab
la
Úni
ca
Resu
men
de
la e
stra
tegi
a :
Tabl
a Ú
nica
Ventajas• El más simple a implementar.• El rendimiento de esta estrategia es mejor que las
otras estrategias.
Desventajas• Campos sin usar• Todos los campos deben aceptar nulos• No esta normalizado
Jerarquía con subtipos• Mas adecuado que en primera instancia difieren
únicamente por el comportamiento.• Mas adecuado si no se tiene requerimientos de datos
únicos
Anot
ació
n @
Dis
crim
inat
orCo
lum
npublic interface DiscriminatorColumn extends ... {
define una columna en la tabla que señala el tipo de fila
String name() default “DTYPE”Nombre de la columna que almacena el tipo de la fila
DiscriminatorType discriminatorType() default STRINGTipo de dato de la columna “name”
String columnDefinition();Definición explicita de la columna
int length()Longitud de la cadena para tipos STRING
enum DiscriminatorTypeSTRINGCHARINTEGER
Anot
ació
n @
Dis
crim
inat
orVa
lue
public interface DiscriminatorValue extends ... {Define el valor de la columna para la columna discriminadora
String value() por defectoString – nombre de la entidadCHAR – valor específicoINTEGER – valor específico
Anot
ació
n @
Inhe
ritan
cepublic interface Inheritance extends ...{
InheritanceType strategy() por defecto SINGLE_TABLE
enum InheritanceTypeSINGLE_TABLE
Una tabla raiz por cada jerarquía de clasesTABLE_PER_CLASS
Una tabla por cada clase concretaJOINED
Una tabla por cada clase en la jerarquía
Estr
ateg
ia d
e H
eren
cia:
Tab
la
por C
lase
Con
cret
a
Resu
men
de
la e
stra
tegi
a :
Tabl
a po
r Cla
se C
oncr
eta
Ventajas • Podría tener campos nulos.• Permite restricciones definidas en la base de datos.
Desventajas• Columnas redundantes en múltiples tablas.• Requiere mas esfuerzo en la implementación• No-normalizado• Menos deseable desde el punto de vista del rendimiento y
portabilidad
Jerarquía con subtipos • Mas adecuado si that do not need to be manipulated with sibling types
Estr
ateg
ia d
e H
eren
cia:
Tab
la
por S
ub-C
lase
(Joi
n)
Resu
men
de
la e
stra
tegi
a :
Tabl
a po
r Sub
-Cla
se (J
oin)
Ventajas• Normalizado.• Podría tener campos nulos.• Permite restricciones definidas en la base de datos.
Desventajas • Requiere «join»
Jerarquía con subtipos• Mas adecuado si existen requerimientos de
propiedad únicas.• Mas adecuado si existen restricciones de base de
datos.• Mas aecuado si queried across sibling types
Implementación de un flujo de trabajo
Interactúa con otros beans
Accede directamente a la base de datos- operaciones «bulky»
Ejemplo: Registrar Cuenta
vs. Entity Beans- representan datos compartidos en la base de datos- interactúa con datos generalmente al nivel individual de
objeto-fila- Ejemplo: Cuenta
BEANS DE SESIÓN
Ejemplo de un flujo de trabajo bajo el patrón DAO
Cl i ent
User Tr ansact i on Account D AO
f romA ccountAccount
toA ccountAccount
7. 1:
6. 1:
4. 1: < const r uct or > ( )
2. 1: < const r uct or > ( )
8: com m i t ( ) : voi d
7: updat eAccount ( account : Account ) : voi d
6: updat eAccount ( account : Account ) : voi d
5: deposi t ( doubl e) : voi d
4: findAccount ( i nt ) : Account
3: w i t hdr aw ( am ount : doubl e) : voi d
2: findAccount ( i nt ) : Account
1: begi n( ) : voi d
Los bean de sesión eliminan la complejidad en el flujo de trabajo en el Cliente
f rom A ccountAccount
toA ccountAccount
Cl i ent
Tel l er Account D AO
1. 7. 1:
1. 6. 1:
1. 1. 1: < const r uct or > ( )
1. 7: updat eAccount ( ) : voi d
1. 6: updat eAccount ( ) : voi d
1. 5: depos i t ( doubl e) : voi d
1. 4: < const r uct or > ( )
1. 3: findAccount ( i nt ) : Account
1. 2: w i t hdr aw ( ) : voi d
1. 1: findAccount ( i nt ) : Account
1: t r ans f er ( f r om Account : i nt , t oAccount : i nt , am ount : doubl e) : voi d
t r ansact i on i s bei ng done by t he EJ BCont ai ner i n t hi s exam pl e
Bean
s de
Ses
ión
Stat
eles
s/St
atef
ul
Stateless
• No mantiene un estado de conversación.• Cada método ignora que sucedió antes y lo que
sucederá después.• Mantiene un estado de implementación.
• Se comparte entre invocaciones de clientes por separado.
• Un conjunto de procedimientos o un batch de comandos que toman un conjunto de parámetros y retorna un resultado.
• El mas “económico” de implementar, desplegar y escalar.
Stateful
• Mantiene un estado de conversación.• El objeto puede acceder a los valores en caché en
distintas invocaciones• Mantiene un estado de implementación.
• No se comparte entre invocaciones de clientes/objetos por separado.• Los recursos son ubicados para realizar el
trabajo de una única instancia de bean de sesión Stateful. Esa instancia está atada al estado del cliente.
• Capaz de reaccionar a los estados de transacción• p.e. publica un mensaje de error en una
transacción rollback.
JSF pone a disposición del web-master una herramienta muy útil para la conversión de datos entre la vista y el bean administrado
Y como todo en Java, existen casos cuando uno necesita su «converter» personalizados. JSF ofrece un marco de trabajo para el desarrollo de «custom converters»
JSF tiene un mecanismo de validación de datos, el cual ocurre antes que los datos del componente GUI actualicen el modelo en el bean administrado
CONVERTER Y VALIDATOR
Mod
elo
de C
onve
rsió
n
Vistas del Componente GUI• Vista del Modelo
• en el cual los datos son representados como tipos de datos (int, long, double).
• Vista de la Presentación• en el cual los datos son representados de tal manera que el usuario pueda
leerlos y/o modificarlos (java.util.date, ‘dd/mm/yyyy’).
Lo usual• JSF automáticamente convierte los datos del componente entre estas dos
vistas cuando la el tipo de datos de la propiedad del bean administrado asociado al componente es del tipo de dato soportado por el componente.
Que sucede si … ?• Cuando queremos mostrar datos que no son estándares, la
tecnologia JSF nos permite registrar un Converter personalizado para ese tipo de dato.
Paso
s pa
ra c
rear
un Co
nverter
El desarrollador de aplicaciones debe
implementar la clase Converter en
una clase CustomConverter.
El arquitecto de la aplicacion debe
registrar el Converter en el
faces-config.xml.
El autor HTML debe hacer
referencia desde los componentes
GUI hacia el CustomConverter.
Converters de JSFBigDecimalConverterBigIntegerConverterBooleanConverterByteConverterCharacterConverterDateTimeConverterDoubleConverterFloatConverterIntegerConverterLongConverterNumberConverterShortConverter
Todos estos Converters tienen un error asociado a ellos, de tal forma que de no pasar la conversión, el error se visualizará en la pagina.
DateTimeConverter y NumberConverter tienen sus propias etiquetas, esto nos dice que podemos configurar el formato de los datos del componente a través de los atributos de la etiqueta.
Mod
elo
de V
alid
ació
n
Métodos de Validación• Implementar la interfaz Validator que realiza la validación• Implementar un método de validación en el bean administrado
Lo usual• JSF provee un conjunto de Validadores estándares para que el Autor
HTML los inserte en las paginas web, éstos ya están listo para utilizarse.
LongRange Validator
Nótese que existe un mensaje enlazado a la caja de texto, el cual capturará los mensajes de error que se disparen.
Nótese que los valores máximo y mínimo del validador se pueden enlazar a propiedades de un bean administrado.
3 Resumen
» Esta es la arquitectura de desarrollo que debemos respetar desde el inicio de la implementación hasta el despliegue de una aplicación empresarial.
» Esta clase ha tocado las 3 capas de las 5 propuestas. ¿Cuales son estas 3 capas?
RESUMEN
Session Beans Seguridad
Entidades del Negocio
EJB
Controladores Delegados
Archivos de Configuración
WAR
WAR
Interfaces de Usuario
Componentes GUI Personalizados
Richfaces 3.x
My F
aces 1.7
Java Mail
utilitarios
EAR
» Lados de una relación» Lado dueño e inverso
» Tipos de relación» OneToOne
» Unidireccional, Bidireccional» ManyToOne
» Unidireccional, Bidireccional» OneToMany
» Unidireccional (bidireccional igual que en ManyToOne)» ManyToMany
» Unidireccional, Bidireccional» Tipos de colección
» Collection, List, Set, Map» Tipo de Carga (Fetch)
» EAGER y LAZY» Tipo de Cascada
» ALL, PERSIST, REMOVE, MERGE, REFRESH
RESUMEN
» Estrategias de Herencia» Única Tabla por Herencia de Clases
» Simple, rápido, no-normalizado, sin restricciones en base de datos» Tabla por Clase Concreta
» No-normalizado, difícil de manejar polifórmicamente.» Menos portabilidad entre gestores de bases de datos
» Tabla por Sub-Clase (Join)» Normalizado, capaz de definir restricciones
» Converter y Validator» Una de las más grandes ventajas de la tecnología de Java Server Faces es que ofrece un
conjunto de componentes que nos permiten concentrarnos en el proceso de desarrollo.» Más aún, nos permite reutilizar sus interfaces de tal forma que podemos crear componentes
personalizados.
RESUMEN
GRACIAS
O también puedes encontrarla
en .
Saludos!
AULA VIRTUALEncuentra esta presentación en el
Recommended