P2C5 Introducción a JEE5 - II

Aurelio Martín Obando Tá[email protected]

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


•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


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 ... {




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 ... {





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 ... {





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

http://www.slideshare.net/aobandot/

Education

P2C5 Introducción a JEE5 - II