SlideShare una empresa de Scribd logo
1 de 228
Descargar para leer sin conexión
Desarrollo de
Aplicaciones Web II
2
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 3
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
ÍNDICE Página
Presentación 7
Red de contenidos 8
Unidad de aprendizaje 1
Tema 1 : Struts 2 : Gestión de componentes RIA 10
1.1. : Etiquetas Ajax en Struts 2 11
1.2. : Librerías de Dojo y Struts 2 11
1.3. : Librerías JQuery Struts 2 23
Tema 2 : Struts 2: Tópicos de Seguridad y validación 30
2.1. : Etiqueta Token 30
2.2. : Validaciones 32
Unidad de aprendizaje 2
Tema 1 : Introducción a la API de Persistencia 48
1.1. : Entidad 48
1.2. : Metadata 49
1.3. : EntityManager 50
1.4. : Unidad de Persistencia 51
1.5. : Operaciones básicas 43
1.6. : Transacciones 55
1.7. : Ciclo de vida de una Entidad 55
Tema 2 : OR-Mapping con JPA 60
2.1. : Anotaciones 60
2.2. : Manejo de la Llave Primaria 65
2.3. : Generación de la Llave Primaria 65
2.4. : Llave primaria compuesta 69
2.5. : Objetos embebidos 71
Tema 3 : Relaciones entre entidades 76
3.1. : Conceptos básicos 76
4
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
3.2. : Relacion Many To One 78
3.3. : Relacion One to One 80
3.4. : Bidireccionalidad de la relación One-To-One 81
3.5. : Relación One To Many 82
3.6. : Relación Many To Many 84
3.7. : Opciones de Fetch 87
Tema 4 : Lenguaje de Consultas JPQL 90
4.1. : Introducción a JP-QL 90
4.2. : Consultas dinámicas 95
4.3. : Consultas nombradas 97
4.4. : Uso de parámetros 99
4.5. : Ejecucion de Queries 100
4.6. : Sintaxis de JPQL 102
Unidad de aprendizaje 3
Tema 1 : Arquitectura de JSF, Configuración y estructura básica 108
1.1. : Introducción a JSF 108
1.2. : Arquitectura de JSF 109
1.3. : Ciclo de vida de un request 113
1.4. : Facelets 117
1.5. : Managed Bean 125
1.6. : Lenguaje de Expresiones JSF 128
1.7. : Backing Beans 131
Tema 2 : Componentes de Interfaz de usuario 134
2.1. : Introducción 134
2.2. : Arquitectura de Componentes UI 135
2.3. : Librería Core. 139
2.4. : Librería HTML. 145
2.5. : Librería User Interface 154
2.6. : Librería de Componentes Compuestos. 154
Tema 3 : Conversiones, Validaciones y Eventos 158
3.1. : Introducción 158
3.2. : El sistema de Conversión de JSF 158
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 5
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
3.3. : El sistema de Validación de JSF 161
3.4. : El sistema de Mensajes de JSF 162
3.5. : El modelo de Eventos de JSF 166
Tema 4 : Tópicos avanzados de JSF I 174
4.1. : JSF y AJAX 174
4.2. : Integración JSF + JPA 177
4.3. : Empleando otras implementaciones de JSF 178
Tema 5 : Tópicos avanzados de JSF II 184
5.1. : Tablas JSF: Facets, dataTable y panelGrid. 184
5.2. : Mantenimiento de tablas 191
Bibliografía 197
Anexo 1 199
Anexo 2 211
Anexo 3
6
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 7
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
PRESENTACIÓN
El curso de “Desarrollo de Aplicaciones Web II” pertenece a la línea de
Programación dentro de la Carrera de Computación e Informática y brinda un
conjunto de conocimientos y herramientas que permitirán a los alumnos poder
desarrollar aplicaciones web de n-capas utilizando los frameworks Java : Struts-
2, Java Persistence API ( JPA ) y Java Server Faces ( JSF ).
El Manual del curso ha sido diseñado bajo la modalidad de Unidades de
Aprendizaje, las que desarrollan determinados temas a lo largo de las semanas
establecidas para el dictado del curso. Cada capítulo del manual indica los temas
a ser tratados, los logros que se deben alcanzar y los contenidos que se deben
desarrollar. Finalmente, se encontrará las actividades recomendadas que el
alumno deberá desarrollar para reforzar lo trabajado y aprendido en la clase. Se
incluye bibliografía y recursos de Internet que puede colaborar en el logro de un
autoaprendizaje efectivo.
El curso es eminentemente práctico, pero requiere horas adicionales de
investigación y práctica por parte del alumno. Se inicia con un repaso del
Framework Struts-2 para abordar las características que brinda al incorporar
funcionalidades de tipo AJAX con los plug-ins de Dojo y jQuery así como la
utilización de las opciones de validación. Posteriormente, se desarrolla
ampliamente los conceptos de “OR-Mapping” con la especificación JPA (Java
Persistence API) y su implementación en EclipseLink: se abordan las
anotaciones, mapeo y relaciones entre entidades así como los fundamentos
básicos de JP-QL para la construcción de consultas. Finalmente, la tercera
unidad del manual aborda la especificación JSF (Java Server Faces ) tratando
de abarcar gran parte de la funcionalidad que proporciona.
8
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
REDDECONTENIDOS
Desarrollo de Aplicaciones Web II
Tópicos
avanzados
de Struts 2
Gestión de
componentes
RIA
Seguridad y
Validación
Java
Persistence
API
( JPA )
Java Server
Faces
( JSF )
Introducción a
la API de
Persistencia
OR-Mapping
con JPA
Relaciones
entre
entidades
Lenguaje de
Consultas
JPQL
Tópicos
avanzados de
JSF
Conversiones,
Validaciones
y Eventos
Componentes
de Interfaz de
usuario
Arquitectura de
JSF, Configuración
y estructura básica
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 9
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
MANEJO DE TÓPICOS AVANZADOS CON STRUTS 2
LOGRO DE LA UNIDAD DE APRENDIZAJE
• Al término de la unidad, el alumno, empleando opciones de AJAX y
facilidades avanzadas que proporciona el framework Struts-2, construye una
aplicación web de n-capas y la despliega dentro de un servidor de
Aplicaciones Java EE compatible.
TEMARIO
Tema 1: Struts 2 y gestión de Componentes RIA
1.1 Etiquetas AJAX Struts 2
1.2 Librerías DOJO Struts 2.
1.3 Librería jQUERY Struts 2.
Tema 2: Tópicos de Seguridad y Validación con Struts 2
2.1 Etiqueta <s:token>
2.2 Validaciones en Struts 2.
ACTIVIDADES PROPUESTAS
• Los alumnos implementan una sencilla aplicación web para recordar los
conceptos de Struts 2.
• Los alumnos implementan opciones de una aplicación web con Struts 2 y para
utilizar las funcionalidades de Ajax seleccionan indistintamente el plug-in de
Dojo o de jQuery.
• Los alumnos implementan una aplicación web con Struts 2 que utiliza la etiqueta
Token para evitar el problema del “doble submit”.
• Los alumnos implementan validaciones en los formularios de las aplicaciones
web desarrolladas con Struts 2.
UNIDAD DE
APRENDIZAJE
1
10
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
TEMA 1: STRUTS 2 : GESTIÓN DE COMPONENTES RIA.
Struts2 atiende una petición del tipo Request de la siguiente forma:
a. El Request es interpretado por el DispatcherFilter y determina que Action y que
conjunto de Interceptors invocar.
b. Cada Interceptor ejecuta sus acciones previas a la ejecución del método de Action a
invocar
• Si el Interceptor I18nInterceptor intercepta el Action: Se ubicará en la
session del usuario un objeto Locale para utilizar i18n.
• Si el Interceptor ValidationInterceptor intercepta el Action: Se ejecutan
la reglas de validación definidas sobre el Action
• Si el Interceptor AnnotationValidationInterceptor intercepta el Action:
Se chequea en el método a invocar del Action si tiene la anotación
@SkipValidation, en cuyo caso no se realizan validaciones
c. Es ejecutado el método anotado con @Before en el Action
d. Es invocado el método del Action.
e. Es ejecutado el método anotado
con @After en el Action
f. Es ejecutado el método anotado
con @BeforeResult en el Action
g. Cada Interceptor ejecuta sus
acciones posteriores a la ejecución
del método de Action a invocar
• Si el Interceptor
ModelDrivenIntercept
or intercepta el Action:
Luego de la ejecución
del Action se ubicara
en el value stack el
modelo que provee el
Action.
• Si el Interceptor
ParametersIntercepto
r intercepta el Action:
Los parametros
provenientes del
Request se ubican en
el value stack
h. Se examina el resultado obtenido del Action y se determina el Result
correspondiente.
i. Mediante el Result determinado se genera la vista, y según la configuración definida
sobre él se invoca el proceso de generación de la vista.
j. La vista generada retorna al cliente.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 11
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
1.1 ETIQUETAS AJAX Y STRUTS 2
Consultando la Wikipedia: Ajax, acrónimo de Asynchronous JavaScript And XML
(JavaScript asíncrono y XML), es una técnica de desarrollo web para crear
aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se
ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene
la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible
realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa
aumentar la interactividad, velocidad y usabilidad en las aplicaciones.
Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se
requieren al servidor y se cargan en segundo plano sin interferir con la visualización ni
el comportamiento de la página. JavaScript es el lenguaje interpretado (scripting
language) en el que normalmente se efectúan las funciones de llamada de Ajax
mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto
disponible en los navegadores actuales. En cualquier caso, no es necesario que el
contenido asíncrono esté formateado en XML.
Ajax es una técnica válida para múltiples plataformas y utilizable en muchos sistemas
operativos y navegadores dado que está basado en estándares abiertos como
JavaScript y Document Object Model (DOM).
La respuesta del servidor puede ser un formato XML, HTML, texto puro, otro Script o
cualquier otro formato que el JavaScript invocador requiera.
Struts 2 soporta AJAX de dos maneras fundamentales:
• Cuando se devuelve un “Response” vía “Stream” de datos
• Cuando se devuelve un “Response” vía JSON (JavaScript Object Notation )
1.2 LIBRERÍA DE TAGS PARA DOJO STRUTS2:
Para usar los tags de AJAX se debe:
- Incluir el plugin de Dojo en el foólder /WEB-INF/lib (distribuido con Struts2 ) .
- Agregar la taglib a cada página:
12
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
<%@taglib prefix=”sx” uri=”/struts<%@taglib prefix=”sx” uri=”/struts<%@taglib prefix=”sx” uri=”/struts<%@taglib prefix=”sx” uri=”/struts----dojodojodojodojo----tags %>tags %>tags %>tags %>
- Incluir el tag <sx:head> en la página y configurarlo para propósitos de
desempeño o de depuración.
Muchos ejemplos se pueden encontrar en la documentación y guías del proyecto
Struts2.
Los tags para manejo de funciones AJAX son:
• a
• autocompleter
• bind
• datetimepicker
• div
• head
• submit
• tabbedPanel
• textarea
• tree
• treenode
Tag <sx:autocompletar>
Este tag es un combo box que permite autocompletar el texto ingresado en la caja de
entrada.
Si se emplea un “action” para cargar el autocompletar, la salida de dicha “action” debe
ser en formato JSON.
Este tag emplea las siguientes reglas para ubicar la fuente de datos:
a) Si la respuesta en un arreglo, se asume que contiene elementos de dos
dimensiones:
b) Si se especifica un valor en el atributo “dataFieldName” y la respuesta tiene un
campo con dicho nombre, se asume que esa es la fuente de datos, la cual debe ser un
arreglo de elementos de dos dimensiones o en todo caso un Map. Por ejemplo,
asumiendo que “datafieldName” tiene el valor “state”:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 13
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
O como mapa:
c) Si existe un campo que comienza con el valor especificado en el atributo “name”,
se asume que esa es la fuente de datos. Por ejemplo, asumiendo que “name” tiene el
valor “state”:
d) Se emplea el primer arreglo que se encuentra. Ejemplo:
e) Si hay un Map, se usa:
Ejemplo: Crear un action que tenga el código siguiente:
14
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
No olvidar los “getter/setter”.
Observe que hay una lista que se llama “paises” y que además hay una variable que
se llama “pais”.
Luego, crear una página que utilice los tags:
Observe que:
• En la línea 2 se requiere definir la “taglib” de Struts2
• En la línea 3 se requiere definir la “tablig” de los tags que se manejan con Dojo.
• También, es importante hacer la declaración de <sx:head /> para que se
incluyan las librerías de javaScript necesarias.
• Luego, en la línea 13 se utiliza el tag de “autocompletar”. Considere que el
atributo “list” se asocia vía OGNL con la variable “países” del Action
“Ejemplo01” y que el atributo “name” se asocia a la variable “país” cuando se
seleccione algún país de la lista.
Si se escribe la primera letra de algún país, debe aparecer la lista desplegable con los
países respectivos:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 15
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Tag <sx:datetimepicker>
Este tag muestra un calendario dentro de una ventana contenedora.
La sintaxis que soporta el atributo “displayFormat” es:
Formato Descripción
d Día del mes
D Día del año
M Mes:
• Usar M o MM para el número de mes.
• MMM para la abreviación del mes
• MMMM para el nombre del mes
• MMMMM para el nombre ajustado.
y Año
h Hora ( en formato de 1-12)
H Hora ( en formato 0-24 )
m Minutos
s Segundos
Ejemplo:
16
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 17
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Tag <sx:div>
Este tag genera una marca HTML de tipo <div> que permite cargar contenido
utilizando llamadas XMLHttpRequest mediante el Framework de Dojo.
Cuando se coloca un valor a “updateFreq”, el timer interno inicia de forma automática y
recarga el contenido de la zona cada vez que se produzca el periodo de refresco (en
milisegundos ).
Se pueden emplear “Topics” para detener (stopTimerListenTopics) o iniciar
(startTimerListenTopics) el timer.
Cuando se usa este tag dentro de un “tabbedpanel”, cada “div” se convierte en un
“tab” por lo que en este caso, existen algunos atributos específicos:
• refreshOnShow : el contenido del “div” es cargado cuando se selecciona el
“tab”.
• closable : el “tab” tiene un botón de close.
• preload: el contenido del “div” se carga inmediatamente después que a página
es cargada.
Tag <sx:tabbedPanel>
Este tag es un componente primario de AJAX, donde cada tab puede cargar contenido
local o remoto (que se refresca cada vez que el usuario selecciona el tab ).
Si se coloca el valor de “trae” a “useSelectedTabCookie”, el “id” del “tab” se almacena
en un cookie durante la activación. Cuando se regresa a dicha vista, el cookie se lee y
el “tab” se activa de nuevo.
Si se desea emplear las características de cookie, se debe asegurar de proporcionar
un único “id” para el componente.
Ejemplo:
18
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Observe que en la línea 23, el tab número dos tiene contenido “remoto” ( desde una
URL ) por lo cual, los tags que están inmersos no se mostrarán. El atributo “preload”
indicará si dicho contenido se cargará al momento de seleccionar el tab o al momento
de cargar todo el panel.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 19
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Tag <sx:tree>
Este tag muestra un árbol con soporte AJAX.
Requiere del soporte del tag <sx:treenode>
Tag <sx:treenode>
Muestra una hoja dentro del árbol con soporte a AJAX.
Si el árbol se genera estáticamente:
• rootNode: es el nodo padre desde donde se origina el árbol.
• nodeIdProperty : propiedad que permite obtener el id del nodo actual.
• nodeTitleProperty: propiedad para obtener el título del nodo actual.
• childCollectionProperty: propiedad que retorna los nodos hijos del nodo actual.
20
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Observe que el anidamiento de los tags <sx:treenode > indica la jerarquía dentro del
árbol.
Si el árbol se genera dinámicamente:
• id : es el id del nodo
• title: es la etiqueta a ser mostrada en el nodo
Ejemplo de tree dinámico:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 21
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Crear una clase “auxiliar”:
No olvidar los getter/Setter. Observe que es una clase simple.
Crear un Action:
Observe que esta clase no tiene getter/setter y se apoya en la clase auxiliar definida
en el paso anterior.
Ahora se genera la página JSP:
22
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 23
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
1.3 LIBRERÍA DE TAGS PARA JQUERY STRUTS2:
Para obtener el plug-in se debe ingresar a Google Code en la ruta siguiente
http://code.google.com/p/struts2-jquery/ y descargar los .jar necesarios de la zona
ubicada al lado derecho de la página (como se muestra en el gráfico ).
Luego proceder a importar el .jar dentro del proyecto.
Para usar los tags de AJAX se debe:
• Incluir el plugin de jQuery en el fólder /WEB-INF/lib (como se muestra en la
imagen anterior ) .
• Agregar la taglib a cada página:
<%@taglib prefix=”sj” uri=”/struts<%@taglib prefix=”sj” uri=”/struts<%@taglib prefix=”sj” uri=”/struts<%@taglib prefix=”sj” uri=”/struts----jqueryjqueryjqueryjquery----tags %>tags %>tags %>tags %>
• Incluir el tag <sj:<sj:<sj:<sj:headheadheadhead>>>> en la página.
Muchos ejemplos se pueden encontrar en la documentación de Google Code.
Los tags para manejo de funciones AJAX son:
• TabbedPanel
Plug-in de jQuery
24
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
• Datepicker
• Dialog
• Accordion
• Autocompleter
• Button
• Buttonset
• Progressbar
• Slider
• Grid
• Richtext Editor
• Charts
• Spinner
Tag <sj:autocompletar>
Este tag genera un campo de tipo autocompletar que puede cargar contenido via
JSON o manejar una lista.
Para personalizar los temas se debe ver la documentación del tah <sj:head>.
Ejemplo: Generar una clase Action que maneje una lista de países:
No olvidar los “getter/setter”.
Ahora, genere una página JSP que haga uso del tag para mostrar la lista de países:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 25
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Observe que:
• En la línea 2 se requiere definir la “taglib” de Struts2.
• En la línea 3 se requiere definir la “tablig” de los tags que se manejan con
jQuery.
• También, es importante hacer la declaración de <sj:head /> para que se
incluyan las librerías de javascript necesarias.
• Luego, en la línea 13 se utiliza el tag de “autocompletar”. Considere que el
atributo “list” se asocia vía OGNL con la variable “paises” del Action
“Ejemplo01” y que el atributo “name” se asocia a la variable “pais” cuando se
seleccione algun país de la lista.
Si se escribe la primera letra de algun país, debe aparecer la lista desplegable con los
nombres de países que contienen dicha letra:
ACTIVIDAD: Cambiar el “theme” para ver como se altera la apariencia de la caja. El
tema se cambia en la zona <sj:head> de la página.
26
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Tag <sj:datepicker>
Este tag sirve para mostrar un calendario.
Requiere que se agrega la librería commons-lang.2.3jar para evitar errores de
ClassNotFoundException al momento de ejecutar el ejemplo.
Tenga en cuenta que se coloca atributos de “theme” y “locale” en la zona de cabecera.
El ejemplo está tomado de la página de documentación de Google (ver referencia).
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 27
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
ACTIVIDAD:
Pruebe cambiar los “themes” en la cabecera de la página para observar cómo se
visualizan los calendarios.
28
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Tag <sj:tabbedpanel>
Este tag genera un panel con varias hojas que pueden cargar contenido vía
invocaciones Ajax.
Ejemplo: Generar una página JSP que emplee dicho tag:
Completar los tags faltantes al final de la página.
Probar
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 29
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
ACTIVIDAD: Generar un tab con contenido remoto.
Este éste caso usamos el atributo “selectedTab” teniendo en cuenta que los “tabs” se
numeran desde cero.
30
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
TEMA 2: TÓPICOS DE SEGURIDAD Y VALIDACIÓN EN STRUTS 2
2.1 ETIQUETA <s:token>
Struts 2 proporciona el soporte necesario para evitar el doble submit de un formulario
al incorporar un tag personalizado en las páginas web y un interceptor que previene
los requests duplicados.
Struts 2 emplea la siguiente lógica para evitar el procesamiento de requests
duplicados:
a) Se codifica la página web con un token embebido como campo oculto.
b) Se coloca dicho token único dentro de la sesión del usuario.
c) Se envía la página al navegador del usuario.
d) Cuando el formulario es enviado, los dos tokens son comparados.
e) Si los tokens no son idénticos, se retorna el resultado “invalid.token”.
Ejemplo:
La línea 5 introduce un nuevo tag de Struts2 llamado “<s:token>”, el cual se va a
encargar de evitar que la página ejecute un doble submit.
Para manejar el request, se debe declarar un interceptor. Los interceptores
interrumpen la ejecución del request y proporcionan el manejo necesario antes que se
ejecute el código correspondiente a la acción.
El el struts.xml se registra la acción y se debe declarar el interceptor “token” (por
defecto no está dentro del defaultStack) y los posibles resultados:
Observe que el Action está haciendo referencia al interceptor llamado “token” y al
“defaultStack” (líneas con el tag <interceptor-ref> del listado).
• Si todo está bien, se invoca a la página “plantilla-fin.jsp”.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 31
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
• Si hay errores de validación se invoca nuevamente a la página “plantilla-
inicio.jsp”.
• Finalmente, si se ejecuta un doble submit, el interceptor invocará a la página
“plantilla-invalidtoken.jsp”.
Si el usuario ejecuta el submit y luego presiona el botón de “back” para ejecutar un
nuevo submit, se debe mostrar la siguiente pantalla:
Una solución más transparente para el problema del doble submit es el uso del
interceptor “tokenSession”, el cual maneja una lógica un poco más inteligente: en lugar
32
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
de devolver el “invalid.token”, bloquea el request duplicado y devuelve la respuesta del
primer request.
Para ello, debe declararse el interceptor de la siguiente forma:
2.2 VALIDACIONES EN STRUTS 2
Struts 2 proporciona dos Interfaces (implementadas por ActionSupport) en el
framework:
• Validateable : que contiene un único método cuya firma es void validate().
La clase ActionSupport contiene una implementación por defecto que permite
validar mediante configuraciones basadas en XML o en anotaciones.
• ValidationAware: proporciona un grupo de métodos usados para recolectar
mensajes de error relacionados a campos del formulario o propiedades de la
clase Action en general. También se emplea para recolectar mensajes
informativos y determinar si se presentan errores.
Las dos interfaces colaboran dentro del workflow de Struts2, específicamente en el
stack de interceptores: interceptor “validation” e interceptor “workflow”.
Si la validación es satisfactoria, se ejecuta el método respectivo de la clase Action
invocada. En caso que la validación falle, se retorna el resultado denominado “input”.
Si no se define el resultado para “input”, el framework genera un error durante la
ejecución.
En el siguiente gráfico se muestra la arquitectura de validación de Struts 2, la cual
está conformada por tres componentes principales:
• Datos: (domain data) que son las propiedades que residen en el Action de
Struts 2 y que se cargan cuando comienza la ejecución de la acción.
• Metadata de validación: que sirve para asociar cada propiedad con las
validaciones necesarias a ser realizadas en tiempo de ejecución. El framework
permite que se utilicen un archivo XML o anotaciones java.
• Validadores: Un validador es un componente reutilizable que contiene la lógica
para ejecutar la validación.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 33
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
2.2.1 VALIDACIÓN MANUAL
Implementar el método void validate() en una clase Action.
Generar un formulario: “ejemplo01.jsp”
34
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Observe que el formulario llama a un “action” ( que debe estar registrado en el
struts.xml )
Además, observe que entre las líneas #11 a la #15 hay un IF que muestra los
mensajes de error ( si es que hubieran ). Estos mensajes son colocados por la
validación realizada en el Action.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 35
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Ahora, escribir la clase “Action” ( no olvidar los getter/setter de las variables ):
Ejecutar la aplicación:
36
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Si se presiona el botón “Registrarse” sin haber ingresado ningún dato, debe salir la
siguiente pantalla (mostrando el mensaje de validación):
Observe el mensaje debajo del campo que se ha validado. Una vez solucionado el
problema, presionamos nuevamente el botón “Registrarse” y la aplicación debería
seguir su curso normal.
2.2.2 VALIDACIÓN USANDO XML
Una validación más compleja utilizando las facilidades que nos brinda el framework de
Struts-2.
Crear una página JSP similar al caso anterior.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 37
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Escribir la clase “Action” pero sin el método “validate” del ejemplo anterior (no olvidar
los getter/setter):
Escribir las validaciones de los campos “nombre” y “apellido”. Para ello se debe crear
un archivo XML a la misma altura en donde está definido el Action.
El nombre del archivo debe seguir la norma:
<Nombre del Action>-validation.xml
En este caso sería Ejemplo2-validation.xml cuyo contenido es:
38
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Este archivo tiene dos formas de validación:
• Usando “<validator>”: observe que el nombre del campo a validar se pasa
como parámetro.
• Usando “<field>”: observe que el nombre del campo se asigna directamente en
el atributo “name”.
Cuando las validaciones son muy simples, no interesa cual de las dos formas se
utilice, pero a medida que las validaciones se hacen más complejas, es preferible
emplear la forma “field” que hace mucho más entendible la lectura del archivo.
2.2.3 VALIDACIONES MÁS COMPLEJAS CON XML
Sobre la base del ejemplo anterior, se hará un poco más complejo el contenido del
archivo XML de validaciones.
El action es bastante sencillo ( no olvidar los getter/setter):
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 39
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
La parte importante de este ejemplo es el archivo de validación XML que utiliza éste
Action:
• Note que ahora se utiliza el formato <field> para validar dos cosas:
Que se ingrese un texto en el campo “nombre”
Que el texto ingresado cumpla con una longitud mínima.
• Observe que se pasa como parámetro “minLength” y que en el texto del
mensaje se puede emplear expresiones de OGNL para recuperar valores que
se encuentran en el stack.
40
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
2.2.4 VALIDACIONES USANDO ARCHIVO .properties
En este ejemplo, los textos de los mensajes se tomarán desde un archivo .properties
(considerar que lo mismo sirve para i18N ).
Crear una clase Action (no olvidar los getter/setter ):
Configurar el archivo de validación: Ejemplo4-validation.xml
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 41
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Y generar un archivo .properties a nivel de PAQUETE:
Cuyo contenido es:
Note que el texto tiene expresiones OGNL que referencian a parámetros propios del
archivo de validación.
El resultado es similar a la siguiente pantalla:
42
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
2.2.5: VALIDACIONES DISPONIBLES EN STRUTS-2
requiredstring:
Tiene un parámetro adicional que es “trim” el cual por defecto es TRUE.
La particularidad de este parámetro es que sólo ejecuta el TRIM para efectos de
verificación de la longitud, más no para enviar el valor al Action (OJO con esto).
stringlength:
Tiene parámetros como “trim”, “maxlength”, “minlength”. En el caso del “trim”, se
comporta igual que en “requiredstring”.
Ejemplo:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 43
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
int:
Tiene como parámetros “min” y “max”. Si se especifican los dos parámetros, el
framework verifica que el valor ingresado esté dentro del rango ( intervalo cerrado ).
double:
Permite comparaciones de rango que incluyen o no a los extremos. Tiene como
parámetros a: “minInclusive”, “maxInclusive”, “minExclusive”, “maxExclusive” en donde
cualquier combinación es permitida.
email:
Es una subclase del validador “regex” y permite validar la sintaxis de una dirección de
correo electrónico.
url:
A diferencia del validador “email”, este validador no es una subclase de “regex”. Al
contrario, utiliza las características del constructor de java.net.URL para verificar la
sintaxis de una dirección URL.
date:
Tiene los parámetros “min” y “max” para validar rangos de fechas.
Recordar que el servidor recibe los parámetros en formato STRING.
regex:
Este validador acepta expresiones regulares (en sintaxis Java) y valida el valor
ingresado contra la expresión dada. Si el campo a ser validado es obligatorio se debe
usar el validador “requiredstring”.
Este validador acepta parámetros “trim”, “caseSensitive” cuyo valor por defecto es
TRUE.
expression y fieldexpression:
Ambos validadores toman expresiones OGNL en el parámetro “expression” para
evaluarlo y determinar si hubo éxito o falla.
44
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Se recomienda realizar evaluaciones más complejas dentro del método “validate()”
antes que en el archivo –validation.xml.
Se puede combinar la validación en el código con el archivo XML simplemente
invocando a: super.validate().
Ejemplo:
2.2.6: VALIDACIÓN USANDO ANOTACIONES
También se puede utilizar las validaciones vía anotaciones en el código Java.
Estos validadores requiere obligatoriamente el atributo “message” aun y cuando se
especifique el atributo “key”. El parámetro “message” es utilizado como mensaje por
defecto si es que la “key” no puede ser ubicada en el archivo de recursos.
Adicionalmente, las expresiones OGNL están disponibles para las anotaciones.
@Validation
Se puede ubicar a nivel de método o a nivel de setter de una propiedad.
Es una anotación que se utiliza sin parámetros. Solía ser obligatoria, pero ya no es
necesario.
@Validations
Se aplica a nivel de método y permite agrupar las validaciones.
Los grupos disponibles son:
• requiredFields
• requiredStrings
• intRangeFields
• stringLengthFields
• regexFields
• emails
• urls
• dateRangeFields
• expressions
• fieldExpressions
• customValidators
• visitorFields
Esta anotación no es específica por método. Esto significa que todas las validaciones
son ejecutadas para todos los métodos de la clase Action.
Ejemplo:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 45
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
@SkipValidation
Esta anotación sirve para marcar los métodos que deben ser excluídos de la
validación.
@RequiredFieldValidator
Es equivalente al validador “required”.
Es obligatorio el ingreso del atributo “message” aun y cuando se haya colocado un
valor al atributo “key”.
@IntRangeFieldValidator
Funciona de la misma forma que el validador “int” utilizado en XML. Soporta los
valores de “max” y “min”.
Otros validadores
El comportamiento es similar a los validadores usados en XML. La documentación del
framework porporciona mayor detalle:
• @DoubleRangeFieldValidator
• @EmailValidator
• @UrlValidator
• @DateRangeFieldValidator
• @StringRegexValidator
• @ExpressionValidator
• @FieldExpressionValidator
• @ConversionErrorFieldValidator
• @VisitorFieldValidator
46
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Resumen
Recordar que Struts 2 es un framework bastante potente que permite agregar
funcionalidad de tipo Ajax mediante la incorporación de algunos “tags”
proporcionados por algún plug-in que trabaje con librerías de JavaScript como por
ejemplo Dojo o JQuery.
También, Struts 2 proporciona mecanismos para “bloquear” el envío duplicado de
formularios de captura de datos mediante el empleo del tag <s:token>.
Struts 2 permite definir validaciones para los campos de captura de los formularios.
Si desea profundizar estos temas, puede consultar las siguientes páginas.
http://struts.apache.org/2.2.1/docs/ajax-tags.html
Aquí hallará la lista completa de tags Ajax en Struts 2 y ejemplos de uso.
http://code.google.com/p/struts2-jquery/
En esta página, hallará el plug-in de jQuery para Struts 2 así como la
documentación y ejemplos propocionados por Google Code.
http://dojotoolkit.org/
En esta página, hallará documentación sobre el framework Dojo Toolkit.
http://jquery.com/
En esta página, hallará documentación sobre el framework JavaScript JQuery.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 47
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
JAVA PERSISTENCE API ( JPA )
LOGRO DE LA UNIDAD DE APRENDIZAJE
• Al término de la unidad, el alumno, construye una aplicación web de n-capas
utilizando el modelo MVC y toda la funcionalidad provista por el framework
Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel
de modelo y la despliega dentro de un servidor de Aplicaciones Java EE
compatible.
TEMARIO
Tema 1: Introducción a la API de Persistencia
1.1 Entidad
1.2 Metadata
1.3 EntityManager
1.4 Unidad de Persistencia
1.5 Operaciones básicas
1.6 Transacciones
1.7 Ciclo de Vida de una Entidad
ACTIVIDADES PROPUESTAS
• Los alumnos descargan y configuran un entorno de desarrollo con las librerías
de JPA.
• Los alumnos configuraran un servidor de aplicaciones para que ejecute
aplicaciones que manejan JPA.
• Los alumnos desarrollan aplicaciones Java Stand-Alone que trabajen con JPA
para familiarizarse con el framework.
UNIDAD DE
APRENDIZAJE
2
48
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
TEMA 1: INTRODUCCIÓN A LA API DE PERSISTENCIA.
La técnica que permite acortar las diferencias entre el modelo relacional y el modelo
de objetos se conoce como ORM ( Mapeo Relacional a Objetos ). La idea básica se
sustenta en que para mapear los conceptos de un modelo al otro ( o viceversa ) se
requiere de un mediador que maneje de forma automática la transformación.
La historia de JPA se origina en dos frameworks de persistencia bastante utilizados:
en el lado propietario existía TopLink mientras que en el lado “open” estaba Hibernate.
JPA es una especificación basada en el JSR 220 conocido como “Enterprise Java
Bean 3.0” (http://jcp.org/en/jsr/detail?id=220 ).
Al ser una especificación (o un conjunto de API’s) está sujeta a diversas
implementaciones de diversos fabricantes. La idea principal es que sea un Framework
ligero, basado en POJOs y pueda enfrentar desafíos de arquitectura e integración en
aplicaciones empresariales.
Algunas implementaciones de JPA :
Hibernate http://www.hibernate.org/
TopLink http://www.oracle.com/technetwork/middleware/toplink/o
verview/index.html
OpenJPA http://openjpa.apache.org/
EclipseLink http://www.eclipse.org/eclipselink/
1.1 ENTIDAD
El concepto de “Entidad” fue introducido por Peter Chen en un documento llamado
“The Entity-relationship model – Howard a unified view of data” publicado en “ACM
Transactions on Database Systems” en el año de 19761
.
En dicho documento se describía a las entidades como cosas que tenían “atributos” y
“relaciones” con la expectativa de que dichos atributos y relaciones pudieran ser
almacenados en la base de datos.
En la actualidad dicha definición es vigente y dado que cualquier objeto dentro de una
aplicación JPA puede ser una entidad, hay que definir las características que debe
poseer una “Entidad”:
• Persistencia : las entidades pueden ser manipuladas para recuperase en
memoria o ser grabadas en un almacén de datos.
1
Una copia del documento se puede obtener en el enlace:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.1085&rep=rep1&type=pdf
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 49
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
• Identidad: significa que las entidades tienen un identificador que permite
emplearlas de manera inequívoca y diferenciarlas de otras instancias de la
misma entidad. El identificador de la entidad es equivalente a la llave primaria
de una tabla en la base de datos.
• Transaccionalidad: Todas las operaciones ( insertar, modificar o eliminar )
deben realizarse dentro de un contexto transaccional debido a que se requiere
de una transacción para que los cambios sean grabados en la base de datos.
• Granularidad: Las entidades son objetos que pertenecen a un dominio de
negocio, poseen un conjunto de estados y por tanto son relevantes para la
aplicación (no se trata de objetos con tipo primitivo, sino de objetos más
complejos).
1.2 METADATA
Cada entidad tiene asociado una “metadata” que la describe. Dicha información puede
estar almacenada dentro de la entidad Java o puede existir en un archivo externo: en
ambos casos, esa información no se almacena en la base de datos.
Existen dos maneras de especificar la metadata:
• Usando Anotaciones
• Usando XML
Las anotaciones fueron introducidas en la versión JAVA EE 5 y permiten que la
metadata esté incorporada dentro del código fuente Java.
El uso de las anotaciones requiere que se importe el paquete “javax.persistence.*”
dentro de la clase Java que representa a la Entidad.
El uso de XML es una opción alternativa a las anotaciones, aunque su lectura puede
resultar compleja para proyectos grandes.
Un JavaBean cualquiera como el siguiente
Se puede convertir en entidad, simplemente agregándole las anotaciones:
@Entity
@Id
50
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
No se debe olvidar que al ser un JavaBean, sigue las reglas de éste (con los
getter/setter).
1.3 ENTITY MANAGER
La mayoría de llamadas a las API’s de JPA se encapsulan dentro de lo que se conoce
como “Entity Manager” y mediante el cual se puede alcanzar a la base de datos.
Esta encapsulación es implementada dentro de una interface conocida como
EntityManager que es la que ejecuta todo el trabajo de persistencia. Por tanto, una
entidad mientras que no se trabaje con el Entity Manager es un objeto Java simple
como cualquier otro.
Cuando el Entity manager obtiene una referencia a una Entidad, se dice que dicha
entidad está en estado “managed”
El conjunto de entidades en estado “managed” dentro de un Entity Manager se conoce
como “persistence context”.
Los Entity Managers son configurados para trabajar con determinados tipos de
objetos, bases de datos y son implementados por un proveedor (provider) conocido
como “persistence provider”. En términos prácticos este provider es la
implementación de la especificación JPA.
Los Entity Managers se generan a partir de una factoría de tipo
EntityManagerFactory, que genera una especie de plantilla para la persistencia, pero
toma la configuración particular desde una unidad de persistencia conocida como
“persistence unit”, la cual contiene la configuración implícita o explícita (con un
nombre asociado ) para las entidades y para el Entity Manager.
El gráfico2
resume las relaciones entre los conceptos mencionados:
2
FUENTE: “JPA 2: Mastering the Java Persistence API”, pág 23.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 51
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Un Entity Manager se obtiene de la siguiente forma:
1.4 UNIDAD DE PERSISTENCIA
La configuración de una unidad de persistencia se escribe en un archivo llamado
“persistence.xml”, el cual debe estar ubicado dentro del folder META-INF de un
proyecto Java.
Cada unidad de persistencia tiene un nombre, el cual es referenciado por la factoría al
momento de pedirle que genere un EntityManager.
Un archivo persistence.xml puede contener una o más unidades de persistencia,
siendo cada una diferente de la otra.
La estructura básica de un archivo persistence.xml es la siguiente:
Nombre de la “persistence unit”
Debe ser el mismo que aparece
en el archivo persistence.xml
Clase estática
Variable con el Entity Manager cargado
52
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Debido a que es un archivo XML, debe tener un DTD:
Luego viene la definición de la Unidad de persistencia, el proveedor y las clases Java
definidas como entidades:
El valor de RESOURCE_LOCAL indica que la conexión a la base de datos se realizará
desde la misma aplicación ( No emplea Pool de conexiones ).
Después se definen las propiedades de conexión a la base de datos:
Nombre de la “persistence unit”
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 53
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Finalmente se cierran los tags XML:
Observe que las propiedades JDBC ( javax.persistence.jdbc.* ) han sido
estandarizadas en JPA 2.0. En versiones anteriores de JPA, esas propiedades eran
definidas por cada Persistence Provider.
1.5 OPERACIONES BÁSICAS
Para aquellos desarrolladores acostumbrados al SQL en bases de datos relacionales,
la equivalencia es sencilla en JPA:
• SQL INSERT = Método Persist
• SQL SELECT = Método Find ( o también puede usarse el SELECT JPQL )
• SQL UPDATE = Método Merge
• SQL DELETE = Método Remove
El “persist” de una entidad significa crear un objeto en memoria y luego
almacenarlo en la base de datos para recuperarlo posteriormente. Como se ha
mencionado, equivale a insertar uno o más registros en la base de datos.
Si ocurre un error durante la ejecución del “persist”, se lanza la excepción
PersistenceException, la cual debe será propagada, debiendo ser manejada por el
programa.
Se instancia el objeto
Java
Se cargan los valores
de los atributos
Se ejecuta el método “persist”
mediante el EntityManager
54
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Para ubicar a una Entidad empleando el método “find”, generalmente se requiere
sólo una línea de código:
Si la entidad con la llave primara indicada no existe, el EntityManager devolverá
NULL. La aplicación debe verificar el valor antes de usar la variable “emp” en el caso
del ejemplo.
Para eliminar una entidad se hace uso del método “remove”. Sin embargo se
debe tener en consideración que para eliminar una entidad en JPA, primero debe
colocarse en estado “managed”, es decir, debe cargarse al contexto de persistencia.
Como se mencionó anteriormente, si la entidad no existe el EntityManager devolverá
NULL, por lo que se debe evaluar dicha condición antes de invocar al método
“remove”.
Si se envía un valor de NULL al “remove”, JPA lanzará la excepción
java.lang.IlegalArgumentException.
Para actualizar atributos de una entidad, se emplea el método “merge”. Se
requiere ubicar a la entidad antes de actualizarla:
En este ejemplo se está actualizando el apellido del empleado con ID = 8.
variable con el EntityManager cargado
Clase de la Entidad a ser “ubicada”
Evita hacer un “cast”
Llave primaria de la Entidad
Se requiere cargar la entidad
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 55
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
1.6 TRANSACCIONES
El único método que puede estar fuera de una transacción es el “find” dado que no
cambia atributos de las entidades.
En una aplicación Java StandAlone (Java SE), se debe invocar el contexto
transaccional de forma explícita, mientras que en una aplicación Java EE, se asume
que el container proporciona dicho contexto transaccional.
1.7 CICLO DE VIDA DE UNA ENTIDAD
JPA proporciona unos métodos denominados “callbacks” (listeners ) para ejecutar
acciones en los diferentes estados que pueden suceder dentro del ciclo de vida de una
entidad. Por ejemplo, imagine que desea actualizar una entidad, pero antes de hacerlo
debe verificar que algunos datos estén presentes.
En el gráfico se puede apreciar que una entidad no existe hasta que se instancia el
objeto y se graba en la base de datos. De ahí pasa al estado “manejado” o
“administrado” por el EntityManager y luego de ello se puede remover, actualizar,
liberar ( “detach” ) o incluso volver a leer ( refrescar ).
Se inicia una transacción
Se inicia finaliza la
transacción
56
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Las anotaciones que proporciona JPA para manejar los “Callbacks” son:
• @PostLoad : Se ejecuta luego de un “refresh” a la entidad.
• @PrePersist: Se ejecuta antes de insertar la entidad.
• @PostPersist: Se ejecuta después de haber insertado la entidad.
• @PreUpdate: Se ejecuta antes de un update a la entidad.
• @PostUpdate: Se ejecuta después de un update a la entidad.
• @PreRemove: Se ejecuta antes de eliminar la entidad en la base de datos.
• @PostRemove: Se ejecuta después de haber eliminado a la entidad.
Los métodos “callback” se pueden declarar dentro de la misma entidad o también en
una clase Java separada.
Por ejemplo, si de declaran dentro de la misma entidad:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 57
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
En cambio, si se prefiere emplear una clase Java externa, sería así:
a) A la Entidad hay que agregarle la anotación @EntityListeners para indicar
cual es la clase Java que contiene los métodos “callbacks”.
b) Se debe crear una clase Java y escribir los métodos que se requiere manejar
(con las anotaciones del caso).
58
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Resumen
Recordar que JPA es una especificación, por tanto, tiene muchas
implementaciones. El desarrollador debe seleccionar una en particular, siendo las
más conocidas: Open JPA, TopLink, EclipseLink e Hibernate.
Diferenciar entre Entidades y Clases Java
Recordar la ubicación del archivo persistence.xml que debe ir siempre dentro del
folder META-INF.
Recordar para que sirve el EntityManager y la persistence-unit
Las operaciones básicas sobre una Entidad: find, persist, merge, remove
Si desea saber más acerca de estos temas, puede consultar las siguientes
páginas:
http://www.eclipse.org/eclipselink/jpa.php
Aquí hallará una referencia completa a la implementación EclipseLink.
http://www.agiledata.org/essays/mappingObjects.html
Aquí hallará información útil sobre Entidades JPA.
También puede consultar el libro “Pro JPA 2 : Mastering the Java API Persistence”
Capítulos 1,2,4, y 6.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 59
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
JAVA PERSISTENCE API ( JPA )
LOGRO DE LA UNIDAD DE APRENDIZAJE
• Al término de la unidad, el alumno, construye una aplicación web de n-capas
utilizando el modelo MVC y toda la funcionalidad provista por el framework
Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel
de modelo y la despliega dentro de un servidor de Aplicaciones Java EE
compatible.
TEMARIO
Tema 2: OR-Mapping con JPA
2.1. Anotaciones
2.2. Manejo de la Llave Primaria
2.3. Generación de la Llave Primaria
2.4. Llave Primaria Compuesta
2.5. Objetos Embebidos
ACTIVIDADES PROPUESTAS
• Los alumnos escriben clases Java, las convierten en Entidades JPA y trabajan
con tablas relacionales.
• Lós alumnos desarrollan aplicaciones Java stand-alone haciendo uso de
entidades JPA.
UNIDAD DE
APRENDIZAJE
2
60
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
TEMA 2: OR-MAPPING CON JPA
2.1 ANOTACIONES
Las anotaciones pueden clasificarse en dos grupos:
• Anotaciones lógicas describen el modelo de entidades desde el punto de
vista del modelamiento orientado a objetos. Constituyen una especie de
metadata del modelo.
• Anotaciones físicas están relacionadas con el modelo en la base de datos
(modelo físico) y tienen que ver con tablas, columnas, etc.
Las anotaciones dentro de una clase Java se pueden colocar a nivel de atributos o a
nivel de métodos. Si se colocan a nivel de atributos se denomina “Field Access”
mientras que si se coloca a nivel de métodos se denomina “Property Access”.
Es equivalente a:
En la especificación de JPA 2.0 se introduce la anotación @Access permite combinar
los dos modos presentados en el ejemplo. Esta anotación permite sobre escribir el
modo de acceso por defecto, aunque no es muy usual hacerlo.
Para definir una entidad basta con emplear la anotación @Entity y la anotación @Id.
Anotación de tipo
“Field Access”
Anotación de tipo “Property
Access”
NOTA: Siempre va en el GETTER
Atributos de la clase
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 61
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Anotación @Table
Por defecto no es necesario incluir ninguna anotación para referenciar a una tabla.
JPA asume que la tabla se llama igual que la clase Java en donde se define la entidad.
Sin embargo, si se desea especificar un nombre de tabla en particular para asociarlo
con la entidad, es preciso utilizar la anotación @Table con el parámetro “name”
respectivo.
Se puede indicar además, el esquema de base de datos con el atributo “schema” (para
aquellos motores de base de datos que lo soporten):
Se debe tener cuidado con el uso de mayúsculas y minúsculas, pues muchos
manejadores de bases de datos no son sensibles a esto.
Anotación @Basic
Cuando se “persiste” una propiedad de una entidad, el “persistente provider” verifica
que el tipo de dato corresponda a un tipo soportado y trata de pasarlo hacia la base de
datos vía el driver JDBC.
Los tipos de datos soportados son:
Tipos primitivos byte, int, short, long, boolean, char, float
double
Clases que encapsulan a tipos
primitivos
Byte, Integer, Short, Long, Boolean,
Character, Float, Double
Arreglos de bytes y caracteres byte[], Byte[], char[], Character[]
Números java.math.BigInteger, java.math.BigDecimal
Cadenas de caracteres java.lang.String
62
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Tipos de datos que manejan fechas
Java
java.util.Date, java.util.Calendar
Tipos de datos que manejan fecha
JDBC
java.sql.Date, java.sql.Time,
java.sql.Timestamp
Tipos enumerados Cualquiera
Objetos serializables Cualquiera
Se debe tener cuidado con el comportamiento del driver JDBC cuando los tipos de
datos no coinciden entre lo que se define en la entidad y lo que soporta la base de
datos, pues el driver intentará ejecutar la mejor conversión posible.
La anotación @Basic (que es opcional) se utiliza para indicar de forma explícita que
dicho atributo debe ser almacenado en la base de datos.
Anotación @Transient
Se emplea para marcar aquellos atributos de la entidad que NO deben ser guardados
en la base de datos.
Anotación @Column
Es una anotación de tipo físico, pues indica las características físicas de la columna
en la base de datos.
Si no se especifica para un atributo determinado marcado como persistente, JPA
asume que la columna se llama igual que dicho atributo. En cambio, si la columna
tiene un nombre diferente, se deberá especificar con el uso de la anotación
@Column.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 63
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Los elementos que acompañan a la anotación @Column son:
Elemento Descripción Valor por
defecto
String
columnDefinition
(Opcional)
Es el fragmento de SQL utlizado para generar el DDL de la
columna (depende del manejador de base de datos)
“”
boolean
insertable
(Opcional) Indica si la columna ser incluirá dentro de una
sentencia SQL INSERT generada por el Persistence Provider.
true
int length (Opcional) Indica la longitud de la columna en la tabla y
funciona únicamente cuando la columna es un String o cadena
de caracteres.
255
String name (Opcional) Indica el nombre de la columna. POr defecto se
asume que la columna se llama igual que el atributo de la
entidad.
“”
boolean nullable (Opcional) Indica si la columna permite valores nulos. true
int precision (Opcional) Indica la precisión para una columna numérica (
válido solo para columnas decimales ).
0
int scale (Opcional) Indica la escala para una columna numérica (
válido solo para columnas decimales ).
0
String table (Opcional) Indica el nombre de la tabla en donde se asocial la
columna.
“”
boolean unique (Opcional) Se emplea cuando la clave única corresponde a
una sóla columna.
false
boolean
updatable
(Opcional) Indica si la columna ser incluirá dentro de una
sentencia SQL UPDATE generada por el Persistence
Provider.
true
Ejemplo 1:
Ejemplo 2:
Anotación @Lob
Para el manejo de objetos binarios (imágenes o archivos generalmente) se requieren
accesos especiales en el driver JDBC para efectuar conversiones entre el objeto Java
y la columna en la tabla de la base de datos.
La anotación @Lob sirve para indicar que el atributo de dicha entidad requiere
efectuar las conversiones vía JDBC.
Ahora bien, los campos LOB (acrónimo de Large Object) se pueden clasificar de dos
maneras, siendo el manejo de cada manera un tanto diferente:
64
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Si el objeto es … El tipo java a usar es …
Character Large Objets ( CLOB ) • char[]
• Character[]
• String
Binary Large Objects ( BLOB ) • byte[]
• Byte[]
• tipos serializables
En ambos casos, el driver JDBC es responsable de hacer las conversiones entre el
objeto Java y la base de datos.
Ejemplo:
Anotación @Temporal
Sirve para especificar tipos de datos basados en el tiempo. Estos tipos de datos se
pueden clasificar en dos ramas: los que vienen del paquete java.sql y los que viene
del paquete java.util.
En el paquete java.sql los tipos se trabajan directamente:
• java.sql.Date
• java.sql.Time
• java.sql.Timestamp
En cambio, en el paquete java.util:
• java.util.Date
• java.util.Calendar
Anotación
Tipo de dato
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 65
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Se debe especificar la anotación @Temporal y además especificar el atributo
“TemporalType” con uno de los tres valores que representan a cada uno de los tipos
java.sql (DATE, TIME o TIMESTAMP).
Ejemplo:
2.2 MANEJO DE LA LLAVE PRIMARIA
Cada Entidad debe tener una llave primaria. La anotación empleada es @Id sobre el
atributo que contiene la llave. Adicionalmente se puede usar @Column para asociar
al atributo con la columna en la tabla.
Una llave primaria se asume que es “insertable”, pero no puede ser “nullable” o
“updatable” por lo que se debe tener cuidado de no sobre escribir esos atributos salvo
excepciones muy específicas (cuando se manejan relaciones).
Los tipos de datos soportados para una llave primaria son:
Tipos primitivos byte, int, short, long, char
Clases de tipos primitives Byte, Integer, Short, Long , Character
Cadenas de caracteres java.lang.String
Números grandes java.match.BigInteger
Tipos basados en tiempo java.util.Date, java.sql.Date
2.3 GENERACIÓN DE LA LLAVE PRIMARIA
También se conoce como “Generación del ID” y se realiza mediante la anotación
@GeneratedValue. En base a dicha anotación, el “Persistence Provider” genera el ID
para cada entidad, y lo inserta en la columna respectiva.
Se debe tener en cuenta que dependiendo de la estrategia de generación del ID, el
valor obtenido puede que no esté disponible hasta que se ejecute un “flush” o un
“commit” a la transacción.
Anotación
Equivalencia JDBCTipo de dato
java.util.Date
66
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Existen cuatro estrategias posibles (que son un tipo enumerado de “GenerationType”):
• AUTO
• TABLE
• SEQUENCE
• IDENTITY
ESTRATEGIA “GenerationType.AUTO”
Este tipo de estrategia delega en el “Persistence Provider” la selección de la mejor
forma de generación de los “ID”. Cualquiera sea la la forma elegida por el provider, se
confiará en los recursos de la base de datos para la obtención de los ID’s.
En el caso particular de EclipseLink con MySQL, la estrategia AUTO emplea una tabla
denominada “sequence”.
Ejemplo:
ESTRATEGIA “GenerationType.TABLE”
Esta estrategia es la más flexible y portable, pues permite que la aplicación genere
ID’s diferentes de acuerdo a las necesidades.
La tabla requiere de dos columnas, una conteniendo el identificador para generar la
secuencia y la otra columna contiene el último valor generado. Cada fila de la tabla es
un generador diferente para los ID’s.
Un ejemplo sencillo es el siguiente:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 67
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Dado que no se ha especificado el nombre de un “generador” ni el nombre de una
tabla, el Persistence provider seleccionará sus propios valores. Lo más común es que
busque (la tabla debe existir en la base de datos) una tabla como la indicada en la
figura.
¿Qué sucede si se desea especificar una tabla en particular ? Se debe emplear la
anotación @TableGenerator.
Ejemplo:
El atributo “allocationSize” indica el incremento en la generación del ID (para el caso
del ejemplo va de uno en uno ). Por defecto el incremento es 50.
68
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
ESTRATEGIA “GenerationType.SEQUENCE”
Esta estrategia depende de las capacidades de la base de datos para manejar objetos
de tipo “secuencia” (caso de Oracle).
Al igual que en la estrategia TABLE, basta con escribir la anotación para que el
“Persistence Provider” seleccione la mejor secuencia dentro de la base de datos.
Ejemplo:
Si se desea especificar una secuencia en particular, debe indicarse el “generator” y la
anotación @SequenceGenerator. Se debe considerar que la secuencia debe existir
previamente en la base de datos (salvo que la opción de generación de DDL esté
habilitada en nuestra aplicación).
Ejemplo (la secuencia es para Oracle):
Estrategia
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 69
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
ESTRATEGIA “GenerationType.IDENTITY”
Esta estrategia aprovecha las facilidades de la bases de datos para utilizar columnas
de tipo “autoincremento”. Sin embargo es menos eficiente porque el identificador
generado no está disponible hasta después que ocurra el INSERT.
No requiere una anotación para el “generador” dado que el campo autoincremental es
parte de la definición de la tabla que corresponde a la entidad.
Ejemplo:
2.4 LLAVE PRIMARIA COMPUESTA
En algunas situaciones, en donde se requiere que la llave primaria de una entidad esté
compuesta de múltiples atributos.
JPA proporciona dos formas de soportar esta necesidad mediante las anotaciones:
• @IdClass
• @EmbeddedId
Se debe tener en cuenta que:
a) En ambos casos se requiere de una clase Java externa que sea la que maneje
los atributos de la llave primaria.
b) La clase Java que maneja los atributos de la llave primaria, debe implementar
los métodos equals() y hashCode() con el fin que el Persistence Manager
pueda almacenar e identificar las entidades.
c) La clase Java que representa a la llave primaria debe ser pública, implementar
a la interface Serializable y tener un constructor sin argumento.
Ejemplo:
Dada la siguiente tabla “tbmatricula” con una llave primaria compuesta
Estrategia
70
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
La Entidad y la clase Java que maneja la llave primaria pueden representarse así (no
olvidar que se debe generar los métodos getter/setter en ambas clases Java):
Observe que la anotación @IdClass especifica el nombre de la clase Java que
maneja la llave primaria.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 71
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Observe también que la clase Java que maneja la llave primaria no posee
anotaciones. Sin embargo, debe implementar los métodos nombrados líneas arriba:
El método equals() lo que hace es comparar uno a uno los atributos de la llave
primaria contra los atributos de otra entidad para verificar que no se trate de la misma
entidad.
El método hashCode() lo que hace es devolver un código “hash” de los valores de la
llave primaria.
Para consultar una entidad con una llave primaria compuesta sólo se requiere generar
una instancia de la clase que maneja la llave primaria, cargarle los valores necesarios
y pasar dicha variable al EntityManager.
Ejemplo:
2.5 OBJETOS EMBEBIDOS
Un objeto embebido es aquel que es dependiente de una entidad: no tiene identidad
por sí mismo. Entender este concepto es muy útil para el manejo de relaciones entre
entidades.
72
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Si bien, a nivel de Java, los objetos embebidos se administran de forma separada, a
nivel de base de datos, la entidad y la clase embebida se almacenan sobre el mismo
registro de la tabla.
Por ejemplo, en el siguiente gráfico se tiene la entidad “CUSTOMER” y la tabla
“tbcustomer”. Observe que los datos de la dirección pueden constituir una clase
separada:
Si se convierte la dirección en una clase “Embebida” quedaría así:
Anotación
@Embedded
Anotación
@Embeddable
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 73
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Se debe observar que:
a) La Entidad declara un atributo con el tipo de dato de la clase “Address” y a este
atributo le coloca la anotación “@Embedded” para indicar que esa clase es
“embebida”.
b) La clase “Address” NO tiene anotaciones que indiquen que es una entidad.
Unicamente tiene la anotación “@Embeddable” para indicar que hay “otra”
clase que la incluye (o que la referencia).
c) Ambas clases tienen sus getter/setter.
d) Ambas clases deben definirse en el archivo persistente.xml.
e) Finalmente, es importante saber que sólo se puede ejecutar queries sobre la
clase marcada como “Entidad”.
74
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Resumen
Una clase Java se convierte en Entidad al agregar la anotación @Entity. Además,
existen otras anotaciones que permiten el mapeo contra columnas de la tabla en la
base de datos.
Existen cuatro maneras de generar la secuencias para ID’s:
• AUTO
• TABLE
• SEQUENCE
• IDENTITY
Recordar el uso de la anotación @Temporal para tipos de datos que manejan
tiempo.
Revise el libro :“Pro JPA 2 : Mastering the Java API Persistence” Capítulo 4
Si desea saber más acerca de estos temas, puede consultar las siguientes
páginas.
http://www.objectdb.com/api/java/jpa/annotations/orm
Aquí hallará mayor información respecto al tema.
ACTIVIDAD RECOMENDADA
• Buscar mayor información sobre la anotación @Access
• Investigar acerca de tipos enumerados que se manejan con @Enumerated
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 75
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
JAVA PERSISTENCE API ( JPA )
LOGRO DE LA UNIDAD DE APRENDIZAJE
• Al término de la unidad, el alumno, construye una aplicación web de n-capas
utilizando el modelo MVC y toda la funcionalidad provista por el framework
Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel
de modelo y la despliega dentro de un servidor de Aplicaciones Java EE
compatible.
TEMARIO
Tema 3: Relaciones entre entidades
3.1. Conceptos básicos
3.2. Many To One
3.3. One to One
3.4. Bidireccionalidad de la relación One-to-One
3.5. One to Many
3.6. Many to Many
3.7. Opciones de Fetch
ACTIVIDADES PROPUESTAS
• Los alumnos generan Entidades JPA y definen relaciones entre ellas.
• Lós alumnos desarrollan aplicaciones Java haciendo uso de las entidades JPA y
sus relaciones.
UNIDAD DE
APRENDIZAJE
2
76
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
TEMA 3: RELACIONES ENTRE ENTIDADES
3.1 CONCEPTOS BÁSICOS
ROLES
Las relaciones entre entidades tienen tres diferentes perspectivas:
a) La primera es el punto de vista desde un lado de la relación.
b) La segunda en el punto de vista desde el otro lado de la relación.
c) La tercera es la perspectiva global que mira ambos lados de la relación.
Estos “lados” son conocidos como “roles”. Tal es así que en cada relación hay dos
entidades que se relacionan mutuamente de tal manera que cada una cumple un rol
dentro de la relación. Es más, una entidad puede jugar muchos roles dentro de un
modelo.
DIRECCIONALIDAD
Existen maneras de crear, remover y actualizar las relaciones para darles
mantenimiento. Si una entidad tiene relación con otra, existirá un atributo que sirve
para identificar la relación y referirse a la entidad relacionada identificando así el rol
que juega en la relación.
Cuando las entidades se referencian mutuamente se dice que la relación es bi-
direccional. Ejemplo: El empleado sabe en que Proyecto trabaja y el Proyecto conoce
quiénes son sus miembros (las flechas indican el sentido de la dirección).
Si una entidad apunta únicamente a otra, la relación es unidireccional. El empleado
conoce su Dirección, pero la inversa no necesariamente es cierta ( la flecha indica el
sentido de la relación).
Ahora bien, la relación Bi-direccional puede ser descompuesta en dos relaciones uni-
direccionales. Cada relación tendrá un origen (“source” o rol de referencia) y un
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 77
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
destino ( “target” o rol referido ). Se debe tener en cuenta esto, pues el origen y destino
varían según la perspectiva que estemos usando para analizar la relación.
CARDINALIDAD
La cardinalidad de una relación sirve para determinar cuantas instancias de una
entidad existen en cada lado de una misma relación.
Cada rol dentro de la relación tendrá su propia cardinalidad, la cual indicará cuando
exista una sola o muchas instancias.
Por ejemplo, muchos empleados pueden trabajar en el mismo departamento (se
muestra una relación de muchos a uno):
ORDINALIDAD
Un rol puede especificarse de forma más detallada para indicar si puede o no estar
presente en una relación. La ordinalidad sirve para indicar si la entidad “target”
necesita ser especificada cuando la entidad “source” es creada.
Debido a que la ordinalidad es un valor lógico (verdadero o falso) es más práctico
referirse a ella como “opcionalidad” de la relación.
MAPEANDO LA RELACIÓN ENTRE ENTIDADES
Existen básicamente dos formas de asociación:
• Las basadas en valores simples.
• Las basadas en colecciones de valores.
Dentro de esas formas de asociación, existen cuatro formas de “mapeo”:
• Relación One-To-One (valores simples)
• Relación Many-To-One (valores simples)
• Relación One-To-Many (colecciones de valores)
• Relación Many-To-Many (colecciones de valores)
78
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
A nivel de Base de Datos, la relación entre entidades significa que una tabla referencia
a otra tabla: aparece el concepto de “Foreign Key” para indicar aquellos campos de
una tabla que hacen referencia a la “Primary Key” de otra tabla.
A nivel de JPA las columnas que forman la “Foreign Key” se conocen como “Join
Columns” y emplean la anotación @JoinColumn para indicar dicha funcionalidad.
3.2 RELACIÓN MANY-TO-ONE
Es la relación más típica que podemos encontrar en el mundo real.
En UML se requiere que la clase “source” tenga un atributo del tipo de la clase ”target”
para poder navegar hacia ella.
Ejemplo: Si varios Empleados pueden trabajar en un Departamento, la relación de
entidades se puede modela como se muestra a continuación:
Tenga en cuenta que:
a) La clase “source” tienen un atributo que corresponde al tipo de la clase “target”
(observe el atributo “departamento”).
b) A dicho atributo se le debe colocar la anotación @ManyToOne.
Ahora falta llevar la relación al modelo de base de datos siguiente:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 79
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Las tablas físicas están relacionadas mediante la columna “DPTO_ID” en la tabla
“tbempleado” que apunta a la columna “DEPT_ID” en la tabla “tbdepartamento”.
Entonces, la “Join Column” de la relación es la columna “DPTO_ID”.
El lado que tiene a la “Join Column” se conoce como el “OWNER SIDE” de la
relación, mientras que el lado que no tiene a la “Join Column” se conoce como
“INVERSE SIDE”.
En este ejemplo, el lado OWNER es la tabla “tbempleado” y el lado INVERSO es la
tabla “tbdepartamento”.
La anotación @JoinColumn siempre se debe colocar en el lado “OWNER” de la
relación.
La entidad “Employee” debe quedar así (observe la anotación @JoinColumn):
80
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Si no se coloca la anotación @JoinColumn, JPA asume el nombre por defecto, el cual
está formado por el nombre del atributo en la entidad owner seguido de un guión bajo
(“_” ) y concatenado con el nombre de la columna PK en la tabla inversa.
3.3 RELACIÓN ONE-TO-ONE
La relación “Uno a Uno” es casi igual a la relación “Muchos a Uno” con la sola
excepción que una instancia de la entidad “source” puede apuntar a una única
instancia de la entidad “target”. Estrictamente hablando, eso significa que la entidad
“target” no puede ser compartida por otras instancias de la entidad “source”.
A nivel de base de datos esta relación implica un criterio de “unicidad” o llave única en
la “Foreign Key” de la entidad “source”.
Obviamente, se requiere definir la relación en la Entidad “Employee”: para ello se hace
uso de la anotación @OneToOne y también se requiere usar @JoinColumn (en este
caso, la columna de Join es “PARKING_ID”). La entidad “Employee” quedará así:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 81
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
3.4 BIDIRECCIONALIDAD DE LA RELACIÓN ONE-TO-ONE
En algunas situaciones se requiere considerar la relación inversa entre las entidades,
también conocida como bidireccionalidad de la relación. La decisión es un criterio de
modelamiento, más no una obligación a nivel de programación.
Para lograr esto, se requiere que la entidad “target” tenga un atributo de la clase
correspondiente a la entidad “source”. Dicho atributo debe tener la anotación
@OneToOne con el elemento “mappedBy” que indique cual es el atributo de la clase
“source” que contiene la relación y apunta a la entidad “target”.
Ejemplo: en el caso de la entidad “ParkingSpace” (“es el “target” de la relación) se
tendría el siguiente atributo:
Y en el caso de la entidad “Employee” ( que es el “owner” de la relación) tendríamos:
Debe tenerse en cuenta dos reglas:
82
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
a) La anotación @JoinColumn se coloca en la entidad que mapea a la tabla que
contiene la columna de join ( o a la entidad que es “owner” de la relación ).
b) El elemento “mappedBy” debe colocarse a la anotación @OneToOne de la
entidad “inversa” o “target” de la relación.
3.5 RELACIÓN ONE-TO-MANY
Cuando una entidad se asocia con una “colección” de otras entidades estamos ante
una relación de “uno a muchos”.
En el ejemplo del Empleado vs. el Departamento, la relación es bidireccional por
naturaleza. En una relación bidireccional, siempre existen dos “mapeos”: uno por cada
relación.
A nivel de base de datos, las tablas siguen siendo las mismas.
Y a nivel de entidades, la entidad “Employee” es la misma.
Como se tiene que implementar el lado inverso de la relación entre Empleado y
Departamento, se debe modificar la entidad “Department” para agregar la relación
inversa “One-To-Many”: se debe “mapear” una colección de entidades “Empleado”
usando la anotación @OneToMany.
Adicionalmente, como éste es el lado inverso de la relación, se debe usar el atributo
“mappedBy” para indicar cual es el atributo dentro de la entidad “Employee” que
contiene la llave de la relación:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 83
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
NOTA: En este caso se está usando una colección indicado el tipo de los elementos
que almacena dicha colección: Collection<Type>. Esto genera una dependencia al
compilar por lo que no es recomendable.
La otra forma de colocar la relación es especificando el atributo “targetEntity” sin
especificar el tipo de dato contenido en la colección:
Esquemáticamente las dos relaciones se ven así:
84
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Es importante tener en cuenta que:
a) El lado “many-to-one” siempre es el lado “owner” de la relación. En
consecuencia, la anotación @JoinColumn debe estar en dicho lado.
b) El lado “one-to-many” es el lado “inverso”, por lo que el elemento “mappedBy”
debe ser utilizado en este lado.
c) Si no se especifica el “mappedBy”, JPA considera que es una relación
unidireccional de tipo one-to-many por lo que requiere el uso de una tabla de
Join. Tener en cuenta que esto puede ocasionar errores al desarrollar
aplicaciones.
3.6 RELACIÓN MANY-TO-MANY
Cuando una o más entidades se asocian con una “colección” de otras entidades y
dichas entidades tienen relaciones sobrepuestas con las mismas entidades “target”, se
dice que estamos frente a una relación de tipo “Mucho-a-Muchos”.
Por ejemplo: Un “Empleado” pueden trabajar en múltiples “Proyectos” y cada
“Proyecto” puede tener a muchos “Empleados”.
De los ejemplos anteriores podemos manejar las siguientes entidades:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 85
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
La relación “Muchos-a-Muchos” se puede expresar en las dos entidades (“source” y
“target”) utilizando la anotación @ManyToMany. Teniendo en cuenta que:
a) Cuando la relación “Many-To-Many” es bidireccional, ambos lados de la
relación deben tener la anotación @ManyToMany.
b) No existen columnas de join en cada lado de la relación: la única forma de
implementar ésta relación es utilizando una tabla de join, por lo que no existe
manera de determinar CUAL es el lado “owner” de la relación, en
consecuencia, se debe asumir que uno de los lados es el “owner”.
c) Al igual que en las relaciones bidireccionales anteriormente tratadas, el lado
que no sea “owner” debe utilizar el “mapeddBy”, en caso se omita éste
elemento, JPA deducirá que se trata de dos relaciones unidireccionales
separadas.
En el ejemplo, la anotación @ManyToMany debe colocarse en ambas entidades:
86
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
El modelo de base de datos es:
A nivel de base de datos, una “Join Table” consiste simplemente de dos “Foreign Key”
o columnas de join que referencian (cada una) a un lado de la relación.
La anotación @JoinTable se usa para configurar la tabla de join de la relación:
a) Cada columna de Join se distingue dependiendo del papel dentro de la
relación: lado owner o lado inverso.
b) La columna de Join que pertenece al lado “owner” se describe usando el
elemento “joinColumns”.
c) La columna de Join que pertenece al lado “inverse” se describe usando el
elemento “inverseJoinColumns”.
En el ejemplo, falta indicar la JoinTable de la siguiente forma (asumiendo que
Employee es el owner de la relación).
Tenga en cuenta que el elemento “name” dentro de @JoinColumn especifica el
nombre de la columna en la tabla de Join, mientras que el elemento
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 87
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
“referencedColumnName” indica la columna que es “Primary Key” en la tabla que se
encuentra al extremo de la relación (sea owner o inversa).
Y en el lado inverso de la relación se pone el elemento “mappedBy”:
3.7 OPCIONES DE FETCH
Las entidades y sus atributos pueden ser cargados de dos formas:
• LAZY: Cuando se cargan de forma “perezosa”, es decir, se cargan en el
momento en que se requieren.
• EAGER: Cuando se cargan de forma “proactiva”, es decir, al momento de
cargar la entidad “owner” de la relación.
En términos de JPA, se usa el elemento “fetch” acompañando a la anotación de la
relación e indicando el valor de FetchType.LAZY o FetchType.EAGER .
En una relación de valores simples el FetchType por defecto es EAGER.
En una relación de colecciones de valores, el FetchType por defecto es LAZY.
En una relación bidireccional, el FetchType puede ser EAGER en un sentido y LAZY
en el otro dependiendo del tipo de navegación que se desea.
88
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Resumen
Recordar que en JPA, existen cuatro tipos de relaciones entre entidades:
• One To One
• One To Many
• Many To One
• Many To Many
Revise el libro :“Pro JPA 2 : Mastering the Java API Persistence” Capítulo 4
Si desea profundizar más acerca de este tema, puede consultar el siguiente
enlace:
http://www.javaworld.com/javaworld/jw-01-2008/jw-01-jpa2.html
Aquí hallará un ejemplo desarrollado del tema.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 89
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
JAVA PERSISTENCE API ( JPA )
LOGRO DE LA UNIDAD DE APRENDIZAJE
• Al término de la unidad, el alumno, construye una aplicación web de n-capas
utilizando el modelo MVC y toda la funcionalidad provista por el framework
Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel
de modelo y la despliega dentro de un servidor de Aplicaciones Java EE
compatible.
TEMARIO
Tema 4: Lenguaje de Consultas JPQL
4.1. Introducción a JP-QL
4.2. Consultas dinámicas
4.3. Consultas nombradas
4.4. Uso de parámetros
4.5 Ejecucion de Queries
4.6 Sintaxis de JPQL
ACTIVIDADES PROPUESTAS
• Los alumnos desarrollan aplicaciones web que mediante el empleo de JPQL
naveguen en la base de datos utilizando el modelo de entidades JPA y sus
relaciones.
UNIDAD DE
APRENDIZAJE
2
90
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
TEMA 4: LENGUAJE DE CONSULTAS JPQL
JPA soporta dos formas para expresar consultas que recuperan entidades desde una
base de datos:
• El lenguaje de consultas (queries), conocido como Java Persistence Query
language ( JPQL ), es un lenguaje independiente del manejador de base de
datos que trabaja con entidades en lugar de usar tablas.
• La API de criterios, que sirve para construir consultas basadas en objetos Java
en lugar de escribir los queries en strings.
4.1 INTRODUCCIÓN A JPQL
Los antecedentes de JPQL se pueden encontrar en la especificación de EJB 2.0 con el
lenguaje EJB-QL en el cual se introdujo una forma de navegar entre los Beans y sus
relaciones, así como filtros y funciones agregadas.
Los queries operan dentro de una unidad de persistencia y pertenecen a una de las
siguientes clasificaciones:
a) SELECT, son queries que recuperan una o más entidades, filtrando los
resultados si fuera necesario.
b) AGGREGATE, los queries de este tipo son variaciones de los queries del tipo
SELECT, con la salvedad que agrupan resultados para producir información
sumarizada (de ahí la necesidad de usar la cláusula GROUP BY ).
c) UPDATE, son queries que se emplean para actualizar un conjunto de
entidades.
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 91
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
d) DELETE, son queries que se utilizan para remover un conjunto de entidades.
Al utilizar los queries se debe considerar que las entidades son referenciadas por su
nombre. Si una entidad no tiene asignado un nombre de forma explícita, JPA asume el
nombre de la clase como nombre por defecto: este nombre se conoce como “abstract
schema name” de la entidad dentro del contexto del query.
También, es importante resaltar que para los queries es indiferente el uso de
mayúsculas y minúsculas salvo en dos casos: nombre de entidades y nombres de
atributos de cada entidad.
Dada una entidad como la siguiente ( entidad “Employee” ):
El query más sencillo que se pueden ejecutar es:
Observe que la notación es muy similar al SQL normal, pero con ligeras diferencias:
92
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
a) En JPQL, lo que sigue a la cláusula “FROM” es el nombre de la entidad, es
decir, no se coloca el nombre de la tabla (recordar que la Entidad “mapea” a
una tabla).
b) En JPQL, es obligatorio que las entidades sean “calificadas” con un “alias”: en
el caso del ejemplo, el alias es “e”. Este “alias” se conoce como “variable de
identificación”.
c) El alias indicará que el resultado será uno o más entidades del tipo
correspondiente a la entidad.
d) El tipo de resultado de un Query no puede ser una Colección. Debe ser un tipo
simple o una Entidad.
A partir del uso del “alias” para la entidad, se puede utilizar la notación “dot” (el punto
“.”) para referenciar campos persistentes de la entidad. Por ejemplo, si queremos
seleccionar únicamente los nombres de los empleados sería así:
En este caso, como el campo “nombre” es un String, el resultado del query devolverá
uno o más Strings. De la misma forma puede trabajarse para cualquier otro atributo,
sea una lista, colección o campos simples.
El seleccionar algunos campos de la entidad (al igual que en SQL) recibe el nombre de
“proyección”. Se debe tener en cuenta su uso si es que se van a descartar (no usar)
varios atributos de la entidad al momento de generar reportes (dada la sobrecarga que
se genera en el framework JPA ).
En el siguiente ejemplo, se puede seleccionar una entidad que no está en la cláusula
FROM:
Observe que “departamento” es una campo de la entidad “Employee”, pero a la vez es
una Entidad (dada la relación establecida @ManyToOne). Por tanto, el resultado de
ese query será una entidad “Department” obtenida a partir de la relación.
FILTROS
Al igual que en SQL, se puede filtrar los resultados a obtener utilizando la cláusula
WHERE y la notación “dot”.
JPQL incluye operadores como IN, LIKE y BETWEEN, funciones como SUBSTRING y
LENGTH además de soportar subqueries.
Ejemplo:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 93
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
En este ejemplo, el filtro lo constituye el atributo “nombre” de la entidad “Department”
que está vinculada con la entidad “Employee”.
JOIN ENTRE ENTIDADES
Al igual que en SQL, si se desea navegar entre las relaciones de las entidades y
retornar elementos de la colección, se debe ejecutar un JOIN entre entidades.
Se puede ejecutar el JOIN al más puro estilo del tradicional SQL indicando los criterios
de JOIN en la cláusula WHERE.
Sin embargo, JPQL proporciona la facilidad de especificar el JOIN dentro de la
cláusula FROM con la finalidad de expresar el JOIN en términos de la relación
existente entre las entidades: JPA se encargará de armar la sentencia SQL
equivalente.
Un JOIN ocurre si se cumple cualquiera de las siguientes condiciones en el SELECT:
1) Dos o más declaraciones de variables son listadas en la cláusula FROM y
aparecen en la cláusula SELECT.
2) El operador JOIN es empleado para extender a una variable de identificación
usando “expression path”.
3) Un “path expression” en cualquier parte del query navega a través de un campo
de asociación en la misma o en otra entidad.
4) Una o más condiciones WHERE comparan atributos de variables de
identificación diferentes.
Se debe tener en cuenta que ante la ausencia de condiciones de JOIN entre entitades,
se generará un producto cartesiano entre la primera entidad y cada ocurrencia de la
segunda entidad.
INNER JOIN
Un “inner join” entre dos entidades se puede especificar de cualquiera de la maneras
indicadas anteriormente. Sin embargo, la forma preferida es mediante el uso del
operador JOIN en la cláusula FROM.
La sintaxis básica es:
[INNER] JOIN <path_expression> [AS] <identifier>
94
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Ejemplo 1: se asume que “phones” contiene una relación JPA entre “Employee” y
“Phone”
Ejemplo 2: múltiples Joins ( los joins se interpretan de izquierda a derecha desde el
FROM )
OUTER JOIN
Un “outter join” entre dos entidades produce un ámbito en el cual solo un lado de la
relación es requerido para completar el resultado. Por ejemplo, un outer join entre
“Empleado” y “Departamento” mostrará todos los empleados y los departamentos a los
que han sido asignados, pero con la salvedad que el “Departamento” será retornado
únicamente si existe dentro de la relación ( a diferencia de un inner join ).
Su sintaxis es la siguiente:
LEFT [OUTER] JOIN <path_expression> [AS] <identifier>
Ejemplo 1:
FETCH JOIN
Este tipo de Join sirve para ayudar a los programadores a optimizar los accesos a la
base de datos. Permite que los queries especifiquen una o más relaciones que deben
ser navegadas y pre-cargadas por el mecanismo de recuperación de datos de tal
forma que no se ejecuten “lazy load” en tiempo de ejecución. En otras palabras,
reduce la cantidad de accesos a la base de datos.
Ejemplo:
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 95
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
QUERIES AGREGADOS
La sintaxis es muy similar a SQL: se requiere el uso del agrupamiento con GROUP BY
Es opcional el uso del filtro mediante la cláusula HAVING.
JPA incluye cinco funciones agregadas:
• AVG : Promedio aritmético.
• COUNT : Cantidad de repeticiones.
• MIN: Menor valor.
• MAX: Mayor valor.
• SUM: Suma de valores
Ejemplo:
En este ejemplo se obtienen todos los departamentos, la cantidad de empleados de
cada departamento, el sueldo máximo y el sueldo promedio teniendo en consideración
sólo aquellos departamentos que tengan más de 5 empleados.
QUERIES
Existen dos formas para definir “queries” en JP-QL:
• La primera forma es definirlo dinámicamente en tiempo de ejecución como una
cadena de caracteres que se construye de acuerdo al flujo de la aplicación.
Esto implica compilar el “query” cada vez.
• La segunda forma es definir el “query” vía anotación o XML y referenciarlo por
el nombre cada vez que se requiera (algo similar a IBATIS). A diferencia de la
forma anterior, los “queries nombrados” son estáticos, pero son mucho más
eficientes para ser ejecutados.
4.2 CONSULTAS DINÁMICAS
Un query se puede definir de forma dinámica simplemente pasando una cadena de
caracteres con la sentencia JPQL al método createQuery() del EntityManager.
Ahora bien, se puede indicar el resultado esperado o se puede omitir y de esta forma
tendremos un query sin tipo definido ( “unTyped query” ).
96
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Para aquellas aplicaciones que utilizan muchos queries, se debe considerar el costo
de “compilar” la sentencia JPQL:
1) Se ejecuta un “parse” de la cadena JPQL en un árbol de sintaxis para verificar
que esté correctamente escrito.
2) Para cada entidad dentro de la expresión se obtiene la metadata.
3) Se genera la sentencia SQL equivalente.
Se debe tener en consideración (al igual que en JDBC) las implicancias de concatenar
un query y luego pasarlo al EntityManager para evitar la inyección de código SQL
malicioso. Por ello es preferible usar parámetros. También, para aquellos queries
empleados con mayor frecuencia, es preferible usar los queries nombrados (
NamedQueries ).
Un ejemplo con TypeQuery:
La sentencia JP-QL
TypedQuery
Clase que retorna el query
La clase Order.java tiene un método
toString()
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 97
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
Un ejemplo con Query :
4.3 CONSULTAS NOMBRADAS
Este tipo de query sirve para organizar y mejorar el desempeño de una aplicación.
Se define empleado la anotación @NamedQuery, la cual se coloca dentro de la
definición de una Entidad: la anotación define no solamente el nombre del query sino
también la sentencia JPQL en sí.
Se recomienda escribir los queries de manera ordenada de tal forma que ayuden a la
visibilidad y lectura de los mismos dentro de la definición de la entidad.
El nombre del query (atributo “name” ) debe ser único dentro de toda la unidad de
persistencia. Si se hace caso omiso a esta restricción, los resultados pueden ser
imprevisibles en tiempo de ejecución.
Se puede definir múltiples queries nombrados empleando la anotación
@NamedQueries, la cual es un arreglo que acepta varias anotaciones
@NamedQuery.
Ejemplo: El mismo query del ejemplo anterior, pero ahora definido en la clase
Order.java
La clase Order.java tiene un método
toString()
La sentencia JP-QL
Query
Query JPQL
Nombre del Query
98
CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
Se invoca así:
Si deseamos definir varios NamedQueries en la entidad, se tendría que hacer así:
Y se puede invocar así:
Se especifica el nombre del Query
Se especifica que es “NamedQuery”
Query JPQL #1
Query JPQL #2
Anotación
DE S AR RO L L O DE A P LI CA CI ON ES WE B II 99
CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES
4.4 USO DE PARÁMETROS
Los parámetros enviados a un “query” permiten la reutilización de sentencias de forma
tal que las consultas ejecutadas con diferentes parámetros en cada invocación,
retornen diferentes resultados. Es preferible enviar parámetros a las consultas en lugar
de estar construyendo una nueva cadena de caracteres por cada invocación, pues así
se evita compilar repetidas veces los “queries”.
PARÁMETROS NOMBRADOS
Se utilizan cuando dentro de la sentencia JPQL, los parámetros van precedidos por el
símbolo de “:” seguido del nombre del parámetro.
Al momento de ejecutar el query, el programador debe especificar el nombre del
parámetro (empleando el método setParameter ) y el valor a ser cargado para
reemplazarlo dentro de la sentencia JPQL.
Los parámetros nombrados proporcionan claridad al código de la sentencia JPQL
(cuando se utilizan nombres adecuados), por lo que son preferidos respecto a los
parámetros ordinales.
Ejemplo usando parámetros nombrados:
Se especifica el nombre del Query
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii
Manual desarrollo de aplicaciones web ii

Más contenido relacionado

La actualidad más candente

Visual studio 2010
Visual studio 2010Visual studio 2010
Visual studio 2010Fitira
 
Introducción a Java EE
Introducción a Java EEIntroducción a Java EE
Introducción a Java EEPaco Saucedo
 
Generación del midlet HolaMundo utilizando el JWTK
Generación del midlet HolaMundo utilizando el JWTKGeneración del midlet HolaMundo utilizando el JWTK
Generación del midlet HolaMundo utilizando el JWTKJorge Iván Meza Martínez
 
Evaluacion 2 practica visual basic
Evaluacion 2 practica visual basicEvaluacion 2 practica visual basic
Evaluacion 2 practica visual basicing.josefernando
 
Diapositivas Spring Framework- Javier Oliver Fulguera
Diapositivas Spring Framework-  Javier Oliver FulgueraDiapositivas Spring Framework-  Javier Oliver Fulguera
Diapositivas Spring Framework- Javier Oliver FulgueraJavier Oliver Fulguera
 
Curso.de.introducción.net.con.visual.basic.2010
Curso.de.introducción.net.con.visual.basic.2010Curso.de.introducción.net.con.visual.basic.2010
Curso.de.introducción.net.con.visual.basic.2010Wilberth Rojas Aguilar
 
Introduccion a Visual Studio .NET
Introduccion a Visual Studio .NETIntroduccion a Visual Studio .NET
Introduccion a Visual Studio .NETMarvin Romero
 
Fundamentos u3 v1
Fundamentos u3 v1Fundamentos u3 v1
Fundamentos u3 v1Lubas Pc
 
Plataforma de programación Java
Plataforma de programación JavaPlataforma de programación Java
Plataforma de programación JavaAntonio Contreras
 
Desarrollo aplicaciones windows c#
Desarrollo aplicaciones windows c#Desarrollo aplicaciones windows c#
Desarrollo aplicaciones windows c#Roger Campos
 
Proyecto final pdm
Proyecto final pdmProyecto final pdm
Proyecto final pdmjaime zamora
 
Introduccion a Visual Studio .NET
Introduccion a Visual Studio .NETIntroduccion a Visual Studio .NET
Introduccion a Visual Studio .NETjnarchie
 
Introducción Spring Framework
Introducción Spring FrameworkIntroducción Spring Framework
Introducción Spring Frameworkecontinua
 

La actualidad más candente (19)

Introduccion Java
Introduccion JavaIntroduccion Java
Introduccion Java
 
Visual studio 2010
Visual studio 2010Visual studio 2010
Visual studio 2010
 
Introducción a Java EE
Introducción a Java EEIntroducción a Java EE
Introducción a Java EE
 
Introducción a Spring framework
Introducción a Spring frameworkIntroducción a Spring framework
Introducción a Spring framework
 
Framework spring
Framework springFramework spring
Framework spring
 
Spring framework 3
Spring framework 3Spring framework 3
Spring framework 3
 
Generación del midlet HolaMundo utilizando el JWTK
Generación del midlet HolaMundo utilizando el JWTKGeneración del midlet HolaMundo utilizando el JWTK
Generación del midlet HolaMundo utilizando el JWTK
 
Evaluacion 2 practica visual basic
Evaluacion 2 practica visual basicEvaluacion 2 practica visual basic
Evaluacion 2 practica visual basic
 
Diapositivas Spring Framework- Javier Oliver Fulguera
Diapositivas Spring Framework-  Javier Oliver FulgueraDiapositivas Spring Framework-  Javier Oliver Fulguera
Diapositivas Spring Framework- Javier Oliver Fulguera
 
Curso.de.introducción.net.con.visual.basic.2010
Curso.de.introducción.net.con.visual.basic.2010Curso.de.introducción.net.con.visual.basic.2010
Curso.de.introducción.net.con.visual.basic.2010
 
Introduccion a Visual Studio .NET
Introduccion a Visual Studio .NETIntroduccion a Visual Studio .NET
Introduccion a Visual Studio .NET
 
Fundamentos u3 v1
Fundamentos u3 v1Fundamentos u3 v1
Fundamentos u3 v1
 
Curso Java Inacap
Curso Java InacapCurso Java Inacap
Curso Java Inacap
 
Plataforma de programación Java
Plataforma de programación JavaPlataforma de programación Java
Plataforma de programación Java
 
Desarrollo aplicaciones windows c#
Desarrollo aplicaciones windows c#Desarrollo aplicaciones windows c#
Desarrollo aplicaciones windows c#
 
Proyecto final pdm
Proyecto final pdmProyecto final pdm
Proyecto final pdm
 
Spring framework
Spring frameworkSpring framework
Spring framework
 
Introduccion a Visual Studio .NET
Introduccion a Visual Studio .NETIntroduccion a Visual Studio .NET
Introduccion a Visual Studio .NET
 
Introducción Spring Framework
Introducción Spring FrameworkIntroducción Spring Framework
Introducción Spring Framework
 

Destacado

JSON Rules Language
JSON Rules LanguageJSON Rules Language
JSON Rules Languagegiurca
 
Aplicaciones de las TICS- AE Cibertec 2010
Aplicaciones de las TICS- AE Cibertec 2010Aplicaciones de las TICS- AE Cibertec 2010
Aplicaciones de las TICS- AE Cibertec 2010Lea Sulmont
 
Investigacion preliminar
Investigacion preliminarInvestigacion preliminar
Investigacion preliminaredgarcito149
 
Arquitectura del computador rulfix
Arquitectura del computador rulfixArquitectura del computador rulfix
Arquitectura del computador rulfixrulfur
 
Administración 2
Administración 2Administración 2
Administración 2pierre R.
 
Manual 2016 i 01_introducción a los rrhh (1923)
Manual 2016 i 01_introducción a los rrhh (1923)Manual 2016 i 01_introducción a los rrhh (1923)
Manual 2016 i 01_introducción a los rrhh (1923)Pedro Luque
 
Cibertec-cursores
Cibertec-cursoresCibertec-cursores
Cibertec-cursoresjthomburne
 
Javaserver Faces (jsf)
Javaserver Faces (jsf)Javaserver Faces (jsf)
Javaserver Faces (jsf)Enrique Polo
 
Manual ética profesional
Manual ética profesionalManual ética profesional
Manual ética profesionalsandraruthi
 
Arquitectura del microprocesador
Arquitectura del microprocesadorArquitectura del microprocesador
Arquitectura del microprocesadorDILMER OLIVERA
 
PRESENTACION DEL CURSO DE COMPUTACION
PRESENTACION DEL CURSO DE COMPUTACIONPRESENTACION DEL CURSO DE COMPUTACION
PRESENTACION DEL CURSO DE COMPUTACIONedumar2271
 
73872402 50309615-manual-logistica-internacional-0608-1
73872402 50309615-manual-logistica-internacional-0608-173872402 50309615-manual-logistica-internacional-0608-1
73872402 50309615-manual-logistica-internacional-0608-1Monica Fernandez
 
Manual 2013 ii 02 administración ii (0006)
Manual 2013 ii 02 administración ii (0006)Manual 2013 ii 02 administración ii (0006)
Manual 2013 ii 02 administración ii (0006)Chriss Aguilar Anaya
 
Base de datos laboratorio
Base de datos laboratorioBase de datos laboratorio
Base de datos laboratoriofreddy Fred
 
ARQUITECTURA DE COMPUTADORAS
ARQUITECTURA DE COMPUTADORASARQUITECTURA DE COMPUTADORAS
ARQUITECTURA DE COMPUTADORASJimmy Osores
 
proyecto de cesca del mal uso del internet
proyecto de cesca del mal uso del internetproyecto de cesca del mal uso del internet
proyecto de cesca del mal uso del internetKaren Ancco
 
Diapositivas de trabajo de computacion
Diapositivas de trabajo de computacionDiapositivas de trabajo de computacion
Diapositivas de trabajo de computacionPatriciaZapatanga
 

Destacado (20)

JSON Rules Language
JSON Rules LanguageJSON Rules Language
JSON Rules Language
 
Marco Pereyra cibertec 10
Marco Pereyra cibertec 10Marco Pereyra cibertec 10
Marco Pereyra cibertec 10
 
Aplicaciones de las TICS- AE Cibertec 2010
Aplicaciones de las TICS- AE Cibertec 2010Aplicaciones de las TICS- AE Cibertec 2010
Aplicaciones de las TICS- AE Cibertec 2010
 
Investigacion preliminar
Investigacion preliminarInvestigacion preliminar
Investigacion preliminar
 
Arquitectura del computador rulfix
Arquitectura del computador rulfixArquitectura del computador rulfix
Arquitectura del computador rulfix
 
Administración 2
Administración 2Administración 2
Administración 2
 
Manual 2016 i 01_introducción a los rrhh (1923)
Manual 2016 i 01_introducción a los rrhh (1923)Manual 2016 i 01_introducción a los rrhh (1923)
Manual 2016 i 01_introducción a los rrhh (1923)
 
Cibertec-cursores
Cibertec-cursoresCibertec-cursores
Cibertec-cursores
 
Javaserver Faces (jsf)
Javaserver Faces (jsf)Javaserver Faces (jsf)
Javaserver Faces (jsf)
 
Fundamentos de redes
Fundamentos de redesFundamentos de redes
Fundamentos de redes
 
Manual ética profesional
Manual ética profesionalManual ética profesional
Manual ética profesional
 
Arquitectura del microprocesador
Arquitectura del microprocesadorArquitectura del microprocesador
Arquitectura del microprocesador
 
PRESENTACION DEL CURSO DE COMPUTACION
PRESENTACION DEL CURSO DE COMPUTACIONPRESENTACION DEL CURSO DE COMPUTACION
PRESENTACION DEL CURSO DE COMPUTACION
 
73872402 50309615-manual-logistica-internacional-0608-1
73872402 50309615-manual-logistica-internacional-0608-173872402 50309615-manual-logistica-internacional-0608-1
73872402 50309615-manual-logistica-internacional-0608-1
 
Pruebas de software
Pruebas de softwarePruebas de software
Pruebas de software
 
Manual 2013 ii 02 administración ii (0006)
Manual 2013 ii 02 administración ii (0006)Manual 2013 ii 02 administración ii (0006)
Manual 2013 ii 02 administración ii (0006)
 
Base de datos laboratorio
Base de datos laboratorioBase de datos laboratorio
Base de datos laboratorio
 
ARQUITECTURA DE COMPUTADORAS
ARQUITECTURA DE COMPUTADORASARQUITECTURA DE COMPUTADORAS
ARQUITECTURA DE COMPUTADORAS
 
proyecto de cesca del mal uso del internet
proyecto de cesca del mal uso del internetproyecto de cesca del mal uso del internet
proyecto de cesca del mal uso del internet
 
Diapositivas de trabajo de computacion
Diapositivas de trabajo de computacionDiapositivas de trabajo de computacion
Diapositivas de trabajo de computacion
 

Similar a Manual desarrollo de aplicaciones web ii

Aplicaciones web con jakarta struts - Javier Oliver Fulguera
Aplicaciones web con jakarta struts  - Javier Oliver FulgueraAplicaciones web con jakarta struts  - Javier Oliver Fulguera
Aplicaciones web con jakarta struts - Javier Oliver FulgueraJavier Oliver Fulguera
 
Tecnicas de documentacion tesis
Tecnicas de documentacion tesisTecnicas de documentacion tesis
Tecnicas de documentacion tesisLuis Villacres
 
Desarrollo web con html5 + css3 + j script + asp mvc4 (vstudio 2012)
Desarrollo web con html5 + css3 + j script + asp mvc4 (vstudio 2012)Desarrollo web con html5 + css3 + j script + asp mvc4 (vstudio 2012)
Desarrollo web con html5 + css3 + j script + asp mvc4 (vstudio 2012)Pedrito Abiel
 
UDA-Guia de desarrollo
UDA-Guia de desarrolloUDA-Guia de desarrollo
UDA-Guia de desarrolloAnder Martinez
 
Frameworks de Java
Frameworks de JavaFrameworks de Java
Frameworks de Javaragmyl
 
Curso de sistemas información c sharp itlm
Curso de sistemas información   c sharp itlmCurso de sistemas información   c sharp itlm
Curso de sistemas información c sharp itlmjlngaribaldi
 
Presentacion med line ed bennett con ajax y dwr
Presentacion   med line ed bennett con ajax y dwrPresentacion   med line ed bennett con ajax y dwr
Presentacion med line ed bennett con ajax y dwrgarciafjgs
 
Presentacion med line ed bennett con ajax y dwr
Presentacion   med line ed bennett con ajax y dwrPresentacion   med line ed bennett con ajax y dwr
Presentacion med line ed bennett con ajax y dwrdamaji2
 
CURSO APLICACIONES WEB
CURSO APLICACIONES WEBCURSO APLICACIONES WEB
CURSO APLICACIONES WEBSkynet Erp
 
Documentacion struts2 laura.palma
Documentacion struts2 laura.palmaDocumentacion struts2 laura.palma
Documentacion struts2 laura.palmaLaura Palma
 
Desarrollo de aplicaciones empresariales Introducción
Desarrollo de aplicaciones empresariales IntroducciónDesarrollo de aplicaciones empresariales Introducción
Desarrollo de aplicaciones empresariales IntroducciónYesith Valencia
 

Similar a Manual desarrollo de aplicaciones web ii (20)

Curso richfaces 3.3.3 I
Curso richfaces 3.3.3 ICurso richfaces 3.3.3 I
Curso richfaces 3.3.3 I
 
Asp.net 4
Asp.net 4Asp.net 4
Asp.net 4
 
Aplicaciones web con jakarta struts - Javier Oliver Fulguera
Aplicaciones web con jakarta struts  - Javier Oliver FulgueraAplicaciones web con jakarta struts  - Javier Oliver Fulguera
Aplicaciones web con jakarta struts - Javier Oliver Fulguera
 
Tecnicas de documentacion tesis
Tecnicas de documentacion tesisTecnicas de documentacion tesis
Tecnicas de documentacion tesis
 
Documentacion struts 2
Documentacion struts 2Documentacion struts 2
Documentacion struts 2
 
Desarrollo web con html5 + css3 + j script + asp mvc4 (vstudio 2012)
Desarrollo web con html5 + css3 + j script + asp mvc4 (vstudio 2012)Desarrollo web con html5 + css3 + j script + asp mvc4 (vstudio 2012)
Desarrollo web con html5 + css3 + j script + asp mvc4 (vstudio 2012)
 
UDA-Guia de desarrollo
UDA-Guia de desarrolloUDA-Guia de desarrollo
UDA-Guia de desarrollo
 
Documentacionstruts2 luiggi
Documentacionstruts2 luiggiDocumentacionstruts2 luiggi
Documentacionstruts2 luiggi
 
Frameworks de Java
Frameworks de JavaFrameworks de Java
Frameworks de Java
 
Fundamentos de Struts 2
Fundamentos de Struts 2Fundamentos de Struts 2
Fundamentos de Struts 2
 
Curso de sistemas información c sharp itlm
Curso de sistemas información   c sharp itlmCurso de sistemas información   c sharp itlm
Curso de sistemas información c sharp itlm
 
Presentacion med line ed bennett con ajax y dwr
Presentacion   med line ed bennett con ajax y dwrPresentacion   med line ed bennett con ajax y dwr
Presentacion med line ed bennett con ajax y dwr
 
Presentacion med line ed bennett con ajax y dwr
Presentacion   med line ed bennett con ajax y dwrPresentacion   med line ed bennett con ajax y dwr
Presentacion med line ed bennett con ajax y dwr
 
Presentacion med line ed bennett con ajax y dwr
Presentacion   med line ed bennett con ajax y dwrPresentacion   med line ed bennett con ajax y dwr
Presentacion med line ed bennett con ajax y dwr
 
CURSO APLICACIONES WEB
CURSO APLICACIONES WEBCURSO APLICACIONES WEB
CURSO APLICACIONES WEB
 
Documentacion struts2
Documentacion struts2Documentacion struts2
Documentacion struts2
 
Documentacion struts2 laura.palma
Documentacion struts2 laura.palmaDocumentacion struts2 laura.palma
Documentacion struts2 laura.palma
 
Curso online-asp-net-lw
Curso online-asp-net-lwCurso online-asp-net-lw
Curso online-asp-net-lw
 
Curso online-asp-net-lw
Curso online-asp-net-lwCurso online-asp-net-lw
Curso online-asp-net-lw
 
Desarrollo de aplicaciones empresariales Introducción
Desarrollo de aplicaciones empresariales IntroducciónDesarrollo de aplicaciones empresariales Introducción
Desarrollo de aplicaciones empresariales Introducción
 

Último

Matriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxMatriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxPaolaCarolinaCarvaja
 
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfActividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfalejandrogomezescoto
 
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...OLGAMILENAMONTAEZNIO
 
Los mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfLos mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfodalistar77
 
La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....Aaron Betancourt
 
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETDe Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETGermán Küber
 
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfPresentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfymiranda2
 
Análisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfAnálisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfcastrodanna185
 
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSPRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSLincangoKevin
 
Carta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfCarta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfangelinebocanegra1
 
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfTENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfJoseAlejandroPerezBa
 
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...RaymondCode
 
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosEl diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosLCristinaForchue
 
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfInmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfOBr.global
 
Inteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidadInteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidaddanik1023m
 
VIDEOS DE APOYO.docx E
VIDEOS DE APOYO.docx                                  EVIDEOS DE APOYO.docx                                  E
VIDEOS DE APOYO.docx Emialexsolar
 
Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.marianarodriguezc797
 
La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2montoyagabriela340
 

Último (20)

Matriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docxMatriz de integración de tecnologías- Paola Carvajal.docx
Matriz de integración de tecnologías- Paola Carvajal.docx
 
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdfActividad 14_ Diseño de Algoritmos Paralelos.pdf
Actividad 14_ Diseño de Algoritmos Paralelos.pdf
 
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
Actividad 1-PRESENTACIÓN ANIMADA.pptxPreservación y conservación de los docum...
 
Los mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdfLos mejores simuladores de circuitos electrónicos.pdf
Los mejores simuladores de circuitos electrónicos.pdf
 
La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....La Electricidad y La Electrónica.pdf....
La Electricidad y La Electrónica.pdf....
 
BEDEC Proyecto y obra , novedades 2024 - Xavier Folch
BEDEC Proyecto y obra , novedades 2024 - Xavier FolchBEDEC Proyecto y obra , novedades 2024 - Xavier Folch
BEDEC Proyecto y obra , novedades 2024 - Xavier Folch
 
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NETDe Código a Ejecución: El Papel Fundamental del MSIL en .NET
De Código a Ejecución: El Papel Fundamental del MSIL en .NET
 
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdfPresentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
Presentación - Diseño de Algoritmos Paralelos - Grupo 2.pdf
 
Análisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdfAnálisis de artefactos tecnologicos .pdf
Análisis de artefactos tecnologicos .pdf
 
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOSPRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
PRESENTACION DEL TEMA LOS MEJORES SIMULADORES DE CIRCUITOS ELCTRONICOS
 
Carta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdfCarta de Premio y Excel angeline 11-2pdf
Carta de Premio y Excel angeline 11-2pdf
 
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdfTENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
TENDENCIAS DE IA Explorando el futuro de la tecnologia.pdf
 
BEDEC Sostenibilidad, novedades 2024 - Laura Silva
BEDEC Sostenibilidad, novedades 2024 - Laura SilvaBEDEC Sostenibilidad, novedades 2024 - Laura Silva
BEDEC Sostenibilidad, novedades 2024 - Laura Silva
 
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
Actividad 14: Diseño de Algoritmos Paralelos Actividad 14: Diseño de Algoritm...
 
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimosEl diseño de Algoritmos Paralelos.pdf - analisis de algortimos
El diseño de Algoritmos Paralelos.pdf - analisis de algortimos
 
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdfInmersión global en ciberseguridad e IA en la conferencia RSA.pdf
Inmersión global en ciberseguridad e IA en la conferencia RSA.pdf
 
Inteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidadInteligencia artificial dentro de la contabilidad
Inteligencia artificial dentro de la contabilidad
 
VIDEOS DE APOYO.docx E
VIDEOS DE APOYO.docx                                  EVIDEOS DE APOYO.docx                                  E
VIDEOS DE APOYO.docx E
 
Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.Tecnológia 2024.docx.
Tecnológia 2024.docx.Tecnológia 2024.docx.
 
La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2La tablet trabajo en grupo del grado 9-2
La tablet trabajo en grupo del grado 9-2
 

Manual desarrollo de aplicaciones web ii

  • 2. 2 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
  • 3. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 3 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES ÍNDICE Página Presentación 7 Red de contenidos 8 Unidad de aprendizaje 1 Tema 1 : Struts 2 : Gestión de componentes RIA 10 1.1. : Etiquetas Ajax en Struts 2 11 1.2. : Librerías de Dojo y Struts 2 11 1.3. : Librerías JQuery Struts 2 23 Tema 2 : Struts 2: Tópicos de Seguridad y validación 30 2.1. : Etiqueta Token 30 2.2. : Validaciones 32 Unidad de aprendizaje 2 Tema 1 : Introducción a la API de Persistencia 48 1.1. : Entidad 48 1.2. : Metadata 49 1.3. : EntityManager 50 1.4. : Unidad de Persistencia 51 1.5. : Operaciones básicas 43 1.6. : Transacciones 55 1.7. : Ciclo de vida de una Entidad 55 Tema 2 : OR-Mapping con JPA 60 2.1. : Anotaciones 60 2.2. : Manejo de la Llave Primaria 65 2.3. : Generación de la Llave Primaria 65 2.4. : Llave primaria compuesta 69 2.5. : Objetos embebidos 71 Tema 3 : Relaciones entre entidades 76 3.1. : Conceptos básicos 76
  • 4. 4 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC 3.2. : Relacion Many To One 78 3.3. : Relacion One to One 80 3.4. : Bidireccionalidad de la relación One-To-One 81 3.5. : Relación One To Many 82 3.6. : Relación Many To Many 84 3.7. : Opciones de Fetch 87 Tema 4 : Lenguaje de Consultas JPQL 90 4.1. : Introducción a JP-QL 90 4.2. : Consultas dinámicas 95 4.3. : Consultas nombradas 97 4.4. : Uso de parámetros 99 4.5. : Ejecucion de Queries 100 4.6. : Sintaxis de JPQL 102 Unidad de aprendizaje 3 Tema 1 : Arquitectura de JSF, Configuración y estructura básica 108 1.1. : Introducción a JSF 108 1.2. : Arquitectura de JSF 109 1.3. : Ciclo de vida de un request 113 1.4. : Facelets 117 1.5. : Managed Bean 125 1.6. : Lenguaje de Expresiones JSF 128 1.7. : Backing Beans 131 Tema 2 : Componentes de Interfaz de usuario 134 2.1. : Introducción 134 2.2. : Arquitectura de Componentes UI 135 2.3. : Librería Core. 139 2.4. : Librería HTML. 145 2.5. : Librería User Interface 154 2.6. : Librería de Componentes Compuestos. 154 Tema 3 : Conversiones, Validaciones y Eventos 158 3.1. : Introducción 158 3.2. : El sistema de Conversión de JSF 158
  • 5. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 5 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES 3.3. : El sistema de Validación de JSF 161 3.4. : El sistema de Mensajes de JSF 162 3.5. : El modelo de Eventos de JSF 166 Tema 4 : Tópicos avanzados de JSF I 174 4.1. : JSF y AJAX 174 4.2. : Integración JSF + JPA 177 4.3. : Empleando otras implementaciones de JSF 178 Tema 5 : Tópicos avanzados de JSF II 184 5.1. : Tablas JSF: Facets, dataTable y panelGrid. 184 5.2. : Mantenimiento de tablas 191 Bibliografía 197 Anexo 1 199 Anexo 2 211 Anexo 3
  • 6. 6 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
  • 7. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 7 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES PRESENTACIÓN El curso de “Desarrollo de Aplicaciones Web II” pertenece a la línea de Programación dentro de la Carrera de Computación e Informática y brinda un conjunto de conocimientos y herramientas que permitirán a los alumnos poder desarrollar aplicaciones web de n-capas utilizando los frameworks Java : Struts- 2, Java Persistence API ( JPA ) y Java Server Faces ( JSF ). El Manual del curso ha sido diseñado bajo la modalidad de Unidades de Aprendizaje, las que desarrollan determinados temas a lo largo de las semanas establecidas para el dictado del curso. Cada capítulo del manual indica los temas a ser tratados, los logros que se deben alcanzar y los contenidos que se deben desarrollar. Finalmente, se encontrará las actividades recomendadas que el alumno deberá desarrollar para reforzar lo trabajado y aprendido en la clase. Se incluye bibliografía y recursos de Internet que puede colaborar en el logro de un autoaprendizaje efectivo. El curso es eminentemente práctico, pero requiere horas adicionales de investigación y práctica por parte del alumno. Se inicia con un repaso del Framework Struts-2 para abordar las características que brinda al incorporar funcionalidades de tipo AJAX con los plug-ins de Dojo y jQuery así como la utilización de las opciones de validación. Posteriormente, se desarrolla ampliamente los conceptos de “OR-Mapping” con la especificación JPA (Java Persistence API) y su implementación en EclipseLink: se abordan las anotaciones, mapeo y relaciones entre entidades así como los fundamentos básicos de JP-QL para la construcción de consultas. Finalmente, la tercera unidad del manual aborda la especificación JSF (Java Server Faces ) tratando de abarcar gran parte de la funcionalidad que proporciona.
  • 8. 8 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC REDDECONTENIDOS Desarrollo de Aplicaciones Web II Tópicos avanzados de Struts 2 Gestión de componentes RIA Seguridad y Validación Java Persistence API ( JPA ) Java Server Faces ( JSF ) Introducción a la API de Persistencia OR-Mapping con JPA Relaciones entre entidades Lenguaje de Consultas JPQL Tópicos avanzados de JSF Conversiones, Validaciones y Eventos Componentes de Interfaz de usuario Arquitectura de JSF, Configuración y estructura básica
  • 9. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 9 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES MANEJO DE TÓPICOS AVANZADOS CON STRUTS 2 LOGRO DE LA UNIDAD DE APRENDIZAJE • Al término de la unidad, el alumno, empleando opciones de AJAX y facilidades avanzadas que proporciona el framework Struts-2, construye una aplicación web de n-capas y la despliega dentro de un servidor de Aplicaciones Java EE compatible. TEMARIO Tema 1: Struts 2 y gestión de Componentes RIA 1.1 Etiquetas AJAX Struts 2 1.2 Librerías DOJO Struts 2. 1.3 Librería jQUERY Struts 2. Tema 2: Tópicos de Seguridad y Validación con Struts 2 2.1 Etiqueta <s:token> 2.2 Validaciones en Struts 2. ACTIVIDADES PROPUESTAS • Los alumnos implementan una sencilla aplicación web para recordar los conceptos de Struts 2. • Los alumnos implementan opciones de una aplicación web con Struts 2 y para utilizar las funcionalidades de Ajax seleccionan indistintamente el plug-in de Dojo o de jQuery. • Los alumnos implementan una aplicación web con Struts 2 que utiliza la etiqueta Token para evitar el problema del “doble submit”. • Los alumnos implementan validaciones en los formularios de las aplicaciones web desarrolladas con Struts 2. UNIDAD DE APRENDIZAJE 1
  • 10. 10 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC TEMA 1: STRUTS 2 : GESTIÓN DE COMPONENTES RIA. Struts2 atiende una petición del tipo Request de la siguiente forma: a. El Request es interpretado por el DispatcherFilter y determina que Action y que conjunto de Interceptors invocar. b. Cada Interceptor ejecuta sus acciones previas a la ejecución del método de Action a invocar • Si el Interceptor I18nInterceptor intercepta el Action: Se ubicará en la session del usuario un objeto Locale para utilizar i18n. • Si el Interceptor ValidationInterceptor intercepta el Action: Se ejecutan la reglas de validación definidas sobre el Action • Si el Interceptor AnnotationValidationInterceptor intercepta el Action: Se chequea en el método a invocar del Action si tiene la anotación @SkipValidation, en cuyo caso no se realizan validaciones c. Es ejecutado el método anotado con @Before en el Action d. Es invocado el método del Action. e. Es ejecutado el método anotado con @After en el Action f. Es ejecutado el método anotado con @BeforeResult en el Action g. Cada Interceptor ejecuta sus acciones posteriores a la ejecución del método de Action a invocar • Si el Interceptor ModelDrivenIntercept or intercepta el Action: Luego de la ejecución del Action se ubicara en el value stack el modelo que provee el Action. • Si el Interceptor ParametersIntercepto r intercepta el Action: Los parametros provenientes del Request se ubican en el value stack h. Se examina el resultado obtenido del Action y se determina el Result correspondiente. i. Mediante el Result determinado se genera la vista, y según la configuración definida sobre él se invoca el proceso de generación de la vista. j. La vista generada retorna al cliente.
  • 11. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 11 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES 1.1 ETIQUETAS AJAX Y STRUTS 2 Consultando la Wikipedia: Ajax, acrónimo de Asynchronous JavaScript And XML (JavaScript asíncrono y XML), es una técnica de desarrollo web para crear aplicaciones interactivas o RIA (Rich Internet Applications). Estas aplicaciones se ejecutan en el cliente, es decir, en el navegador de los usuarios mientras se mantiene la comunicación asíncrona con el servidor en segundo plano. De esta forma es posible realizar cambios sobre las páginas sin necesidad de recargarlas, lo que significa aumentar la interactividad, velocidad y usabilidad en las aplicaciones. Ajax es una tecnología asíncrona, en el sentido de que los datos adicionales se requieren al servidor y se cargan en segundo plano sin interferir con la visualización ni el comportamiento de la página. JavaScript es el lenguaje interpretado (scripting language) en el que normalmente se efectúan las funciones de llamada de Ajax mientras que el acceso a los datos se realiza mediante XMLHttpRequest, objeto disponible en los navegadores actuales. En cualquier caso, no es necesario que el contenido asíncrono esté formateado en XML. Ajax es una técnica válida para múltiples plataformas y utilizable en muchos sistemas operativos y navegadores dado que está basado en estándares abiertos como JavaScript y Document Object Model (DOM). La respuesta del servidor puede ser un formato XML, HTML, texto puro, otro Script o cualquier otro formato que el JavaScript invocador requiera. Struts 2 soporta AJAX de dos maneras fundamentales: • Cuando se devuelve un “Response” vía “Stream” de datos • Cuando se devuelve un “Response” vía JSON (JavaScript Object Notation ) 1.2 LIBRERÍA DE TAGS PARA DOJO STRUTS2: Para usar los tags de AJAX se debe: - Incluir el plugin de Dojo en el foólder /WEB-INF/lib (distribuido con Struts2 ) . - Agregar la taglib a cada página:
  • 12. 12 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC <%@taglib prefix=”sx” uri=”/struts<%@taglib prefix=”sx” uri=”/struts<%@taglib prefix=”sx” uri=”/struts<%@taglib prefix=”sx” uri=”/struts----dojodojodojodojo----tags %>tags %>tags %>tags %> - Incluir el tag <sx:head> en la página y configurarlo para propósitos de desempeño o de depuración. Muchos ejemplos se pueden encontrar en la documentación y guías del proyecto Struts2. Los tags para manejo de funciones AJAX son: • a • autocompleter • bind • datetimepicker • div • head • submit • tabbedPanel • textarea • tree • treenode Tag <sx:autocompletar> Este tag es un combo box que permite autocompletar el texto ingresado en la caja de entrada. Si se emplea un “action” para cargar el autocompletar, la salida de dicha “action” debe ser en formato JSON. Este tag emplea las siguientes reglas para ubicar la fuente de datos: a) Si la respuesta en un arreglo, se asume que contiene elementos de dos dimensiones: b) Si se especifica un valor en el atributo “dataFieldName” y la respuesta tiene un campo con dicho nombre, se asume que esa es la fuente de datos, la cual debe ser un arreglo de elementos de dos dimensiones o en todo caso un Map. Por ejemplo, asumiendo que “datafieldName” tiene el valor “state”:
  • 13. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 13 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES O como mapa: c) Si existe un campo que comienza con el valor especificado en el atributo “name”, se asume que esa es la fuente de datos. Por ejemplo, asumiendo que “name” tiene el valor “state”: d) Se emplea el primer arreglo que se encuentra. Ejemplo: e) Si hay un Map, se usa: Ejemplo: Crear un action que tenga el código siguiente:
  • 14. 14 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC No olvidar los “getter/setter”. Observe que hay una lista que se llama “paises” y que además hay una variable que se llama “pais”. Luego, crear una página que utilice los tags: Observe que: • En la línea 2 se requiere definir la “taglib” de Struts2 • En la línea 3 se requiere definir la “tablig” de los tags que se manejan con Dojo. • También, es importante hacer la declaración de <sx:head /> para que se incluyan las librerías de javaScript necesarias. • Luego, en la línea 13 se utiliza el tag de “autocompletar”. Considere que el atributo “list” se asocia vía OGNL con la variable “países” del Action “Ejemplo01” y que el atributo “name” se asocia a la variable “país” cuando se seleccione algún país de la lista. Si se escribe la primera letra de algún país, debe aparecer la lista desplegable con los países respectivos:
  • 15. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 15 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Tag <sx:datetimepicker> Este tag muestra un calendario dentro de una ventana contenedora. La sintaxis que soporta el atributo “displayFormat” es: Formato Descripción d Día del mes D Día del año M Mes: • Usar M o MM para el número de mes. • MMM para la abreviación del mes • MMMM para el nombre del mes • MMMMM para el nombre ajustado. y Año h Hora ( en formato de 1-12) H Hora ( en formato 0-24 ) m Minutos s Segundos Ejemplo:
  • 16. 16 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
  • 17. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 17 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Tag <sx:div> Este tag genera una marca HTML de tipo <div> que permite cargar contenido utilizando llamadas XMLHttpRequest mediante el Framework de Dojo. Cuando se coloca un valor a “updateFreq”, el timer interno inicia de forma automática y recarga el contenido de la zona cada vez que se produzca el periodo de refresco (en milisegundos ). Se pueden emplear “Topics” para detener (stopTimerListenTopics) o iniciar (startTimerListenTopics) el timer. Cuando se usa este tag dentro de un “tabbedpanel”, cada “div” se convierte en un “tab” por lo que en este caso, existen algunos atributos específicos: • refreshOnShow : el contenido del “div” es cargado cuando se selecciona el “tab”. • closable : el “tab” tiene un botón de close. • preload: el contenido del “div” se carga inmediatamente después que a página es cargada. Tag <sx:tabbedPanel> Este tag es un componente primario de AJAX, donde cada tab puede cargar contenido local o remoto (que se refresca cada vez que el usuario selecciona el tab ). Si se coloca el valor de “trae” a “useSelectedTabCookie”, el “id” del “tab” se almacena en un cookie durante la activación. Cuando se regresa a dicha vista, el cookie se lee y el “tab” se activa de nuevo. Si se desea emplear las características de cookie, se debe asegurar de proporcionar un único “id” para el componente. Ejemplo:
  • 18. 18 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Observe que en la línea 23, el tab número dos tiene contenido “remoto” ( desde una URL ) por lo cual, los tags que están inmersos no se mostrarán. El atributo “preload” indicará si dicho contenido se cargará al momento de seleccionar el tab o al momento de cargar todo el panel.
  • 19. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 19 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Tag <sx:tree> Este tag muestra un árbol con soporte AJAX. Requiere del soporte del tag <sx:treenode> Tag <sx:treenode> Muestra una hoja dentro del árbol con soporte a AJAX. Si el árbol se genera estáticamente: • rootNode: es el nodo padre desde donde se origina el árbol. • nodeIdProperty : propiedad que permite obtener el id del nodo actual. • nodeTitleProperty: propiedad para obtener el título del nodo actual. • childCollectionProperty: propiedad que retorna los nodos hijos del nodo actual.
  • 20. 20 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Observe que el anidamiento de los tags <sx:treenode > indica la jerarquía dentro del árbol. Si el árbol se genera dinámicamente: • id : es el id del nodo • title: es la etiqueta a ser mostrada en el nodo Ejemplo de tree dinámico:
  • 21. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 21 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Crear una clase “auxiliar”: No olvidar los getter/Setter. Observe que es una clase simple. Crear un Action: Observe que esta clase no tiene getter/setter y se apoya en la clase auxiliar definida en el paso anterior. Ahora se genera la página JSP:
  • 22. 22 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC
  • 23. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 23 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES 1.3 LIBRERÍA DE TAGS PARA JQUERY STRUTS2: Para obtener el plug-in se debe ingresar a Google Code en la ruta siguiente http://code.google.com/p/struts2-jquery/ y descargar los .jar necesarios de la zona ubicada al lado derecho de la página (como se muestra en el gráfico ). Luego proceder a importar el .jar dentro del proyecto. Para usar los tags de AJAX se debe: • Incluir el plugin de jQuery en el fólder /WEB-INF/lib (como se muestra en la imagen anterior ) . • Agregar la taglib a cada página: <%@taglib prefix=”sj” uri=”/struts<%@taglib prefix=”sj” uri=”/struts<%@taglib prefix=”sj” uri=”/struts<%@taglib prefix=”sj” uri=”/struts----jqueryjqueryjqueryjquery----tags %>tags %>tags %>tags %> • Incluir el tag <sj:<sj:<sj:<sj:headheadheadhead>>>> en la página. Muchos ejemplos se pueden encontrar en la documentación de Google Code. Los tags para manejo de funciones AJAX son: • TabbedPanel Plug-in de jQuery
  • 24. 24 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC • Datepicker • Dialog • Accordion • Autocompleter • Button • Buttonset • Progressbar • Slider • Grid • Richtext Editor • Charts • Spinner Tag <sj:autocompletar> Este tag genera un campo de tipo autocompletar que puede cargar contenido via JSON o manejar una lista. Para personalizar los temas se debe ver la documentación del tah <sj:head>. Ejemplo: Generar una clase Action que maneje una lista de países: No olvidar los “getter/setter”. Ahora, genere una página JSP que haga uso del tag para mostrar la lista de países:
  • 25. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 25 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Observe que: • En la línea 2 se requiere definir la “taglib” de Struts2. • En la línea 3 se requiere definir la “tablig” de los tags que se manejan con jQuery. • También, es importante hacer la declaración de <sj:head /> para que se incluyan las librerías de javascript necesarias. • Luego, en la línea 13 se utiliza el tag de “autocompletar”. Considere que el atributo “list” se asocia vía OGNL con la variable “paises” del Action “Ejemplo01” y que el atributo “name” se asocia a la variable “pais” cuando se seleccione algun país de la lista. Si se escribe la primera letra de algun país, debe aparecer la lista desplegable con los nombres de países que contienen dicha letra: ACTIVIDAD: Cambiar el “theme” para ver como se altera la apariencia de la caja. El tema se cambia en la zona <sj:head> de la página.
  • 26. 26 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Tag <sj:datepicker> Este tag sirve para mostrar un calendario. Requiere que se agrega la librería commons-lang.2.3jar para evitar errores de ClassNotFoundException al momento de ejecutar el ejemplo. Tenga en cuenta que se coloca atributos de “theme” y “locale” en la zona de cabecera. El ejemplo está tomado de la página de documentación de Google (ver referencia).
  • 27. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 27 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES ACTIVIDAD: Pruebe cambiar los “themes” en la cabecera de la página para observar cómo se visualizan los calendarios.
  • 28. 28 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Tag <sj:tabbedpanel> Este tag genera un panel con varias hojas que pueden cargar contenido vía invocaciones Ajax. Ejemplo: Generar una página JSP que emplee dicho tag: Completar los tags faltantes al final de la página. Probar
  • 29. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 29 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES ACTIVIDAD: Generar un tab con contenido remoto. Este éste caso usamos el atributo “selectedTab” teniendo en cuenta que los “tabs” se numeran desde cero.
  • 30. 30 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC TEMA 2: TÓPICOS DE SEGURIDAD Y VALIDACIÓN EN STRUTS 2 2.1 ETIQUETA <s:token> Struts 2 proporciona el soporte necesario para evitar el doble submit de un formulario al incorporar un tag personalizado en las páginas web y un interceptor que previene los requests duplicados. Struts 2 emplea la siguiente lógica para evitar el procesamiento de requests duplicados: a) Se codifica la página web con un token embebido como campo oculto. b) Se coloca dicho token único dentro de la sesión del usuario. c) Se envía la página al navegador del usuario. d) Cuando el formulario es enviado, los dos tokens son comparados. e) Si los tokens no son idénticos, se retorna el resultado “invalid.token”. Ejemplo: La línea 5 introduce un nuevo tag de Struts2 llamado “<s:token>”, el cual se va a encargar de evitar que la página ejecute un doble submit. Para manejar el request, se debe declarar un interceptor. Los interceptores interrumpen la ejecución del request y proporcionan el manejo necesario antes que se ejecute el código correspondiente a la acción. El el struts.xml se registra la acción y se debe declarar el interceptor “token” (por defecto no está dentro del defaultStack) y los posibles resultados: Observe que el Action está haciendo referencia al interceptor llamado “token” y al “defaultStack” (líneas con el tag <interceptor-ref> del listado). • Si todo está bien, se invoca a la página “plantilla-fin.jsp”.
  • 31. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 31 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES • Si hay errores de validación se invoca nuevamente a la página “plantilla- inicio.jsp”. • Finalmente, si se ejecuta un doble submit, el interceptor invocará a la página “plantilla-invalidtoken.jsp”. Si el usuario ejecuta el submit y luego presiona el botón de “back” para ejecutar un nuevo submit, se debe mostrar la siguiente pantalla: Una solución más transparente para el problema del doble submit es el uso del interceptor “tokenSession”, el cual maneja una lógica un poco más inteligente: en lugar
  • 32. 32 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC de devolver el “invalid.token”, bloquea el request duplicado y devuelve la respuesta del primer request. Para ello, debe declararse el interceptor de la siguiente forma: 2.2 VALIDACIONES EN STRUTS 2 Struts 2 proporciona dos Interfaces (implementadas por ActionSupport) en el framework: • Validateable : que contiene un único método cuya firma es void validate(). La clase ActionSupport contiene una implementación por defecto que permite validar mediante configuraciones basadas en XML o en anotaciones. • ValidationAware: proporciona un grupo de métodos usados para recolectar mensajes de error relacionados a campos del formulario o propiedades de la clase Action en general. También se emplea para recolectar mensajes informativos y determinar si se presentan errores. Las dos interfaces colaboran dentro del workflow de Struts2, específicamente en el stack de interceptores: interceptor “validation” e interceptor “workflow”. Si la validación es satisfactoria, se ejecuta el método respectivo de la clase Action invocada. En caso que la validación falle, se retorna el resultado denominado “input”. Si no se define el resultado para “input”, el framework genera un error durante la ejecución. En el siguiente gráfico se muestra la arquitectura de validación de Struts 2, la cual está conformada por tres componentes principales: • Datos: (domain data) que son las propiedades que residen en el Action de Struts 2 y que se cargan cuando comienza la ejecución de la acción. • Metadata de validación: que sirve para asociar cada propiedad con las validaciones necesarias a ser realizadas en tiempo de ejecución. El framework permite que se utilicen un archivo XML o anotaciones java. • Validadores: Un validador es un componente reutilizable que contiene la lógica para ejecutar la validación.
  • 33. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 33 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES 2.2.1 VALIDACIÓN MANUAL Implementar el método void validate() en una clase Action. Generar un formulario: “ejemplo01.jsp”
  • 34. 34 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Observe que el formulario llama a un “action” ( que debe estar registrado en el struts.xml ) Además, observe que entre las líneas #11 a la #15 hay un IF que muestra los mensajes de error ( si es que hubieran ). Estos mensajes son colocados por la validación realizada en el Action.
  • 35. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 35 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Ahora, escribir la clase “Action” ( no olvidar los getter/setter de las variables ): Ejecutar la aplicación:
  • 36. 36 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Si se presiona el botón “Registrarse” sin haber ingresado ningún dato, debe salir la siguiente pantalla (mostrando el mensaje de validación): Observe el mensaje debajo del campo que se ha validado. Una vez solucionado el problema, presionamos nuevamente el botón “Registrarse” y la aplicación debería seguir su curso normal. 2.2.2 VALIDACIÓN USANDO XML Una validación más compleja utilizando las facilidades que nos brinda el framework de Struts-2. Crear una página JSP similar al caso anterior.
  • 37. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 37 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Escribir la clase “Action” pero sin el método “validate” del ejemplo anterior (no olvidar los getter/setter): Escribir las validaciones de los campos “nombre” y “apellido”. Para ello se debe crear un archivo XML a la misma altura en donde está definido el Action. El nombre del archivo debe seguir la norma: <Nombre del Action>-validation.xml En este caso sería Ejemplo2-validation.xml cuyo contenido es:
  • 38. 38 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Este archivo tiene dos formas de validación: • Usando “<validator>”: observe que el nombre del campo a validar se pasa como parámetro. • Usando “<field>”: observe que el nombre del campo se asigna directamente en el atributo “name”. Cuando las validaciones son muy simples, no interesa cual de las dos formas se utilice, pero a medida que las validaciones se hacen más complejas, es preferible emplear la forma “field” que hace mucho más entendible la lectura del archivo. 2.2.3 VALIDACIONES MÁS COMPLEJAS CON XML Sobre la base del ejemplo anterior, se hará un poco más complejo el contenido del archivo XML de validaciones. El action es bastante sencillo ( no olvidar los getter/setter):
  • 39. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 39 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES La parte importante de este ejemplo es el archivo de validación XML que utiliza éste Action: • Note que ahora se utiliza el formato <field> para validar dos cosas: Que se ingrese un texto en el campo “nombre” Que el texto ingresado cumpla con una longitud mínima. • Observe que se pasa como parámetro “minLength” y que en el texto del mensaje se puede emplear expresiones de OGNL para recuperar valores que se encuentran en el stack.
  • 40. 40 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC 2.2.4 VALIDACIONES USANDO ARCHIVO .properties En este ejemplo, los textos de los mensajes se tomarán desde un archivo .properties (considerar que lo mismo sirve para i18N ). Crear una clase Action (no olvidar los getter/setter ): Configurar el archivo de validación: Ejemplo4-validation.xml
  • 41. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 41 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Y generar un archivo .properties a nivel de PAQUETE: Cuyo contenido es: Note que el texto tiene expresiones OGNL que referencian a parámetros propios del archivo de validación. El resultado es similar a la siguiente pantalla:
  • 42. 42 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC 2.2.5: VALIDACIONES DISPONIBLES EN STRUTS-2 requiredstring: Tiene un parámetro adicional que es “trim” el cual por defecto es TRUE. La particularidad de este parámetro es que sólo ejecuta el TRIM para efectos de verificación de la longitud, más no para enviar el valor al Action (OJO con esto). stringlength: Tiene parámetros como “trim”, “maxlength”, “minlength”. En el caso del “trim”, se comporta igual que en “requiredstring”. Ejemplo:
  • 43. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 43 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES int: Tiene como parámetros “min” y “max”. Si se especifican los dos parámetros, el framework verifica que el valor ingresado esté dentro del rango ( intervalo cerrado ). double: Permite comparaciones de rango que incluyen o no a los extremos. Tiene como parámetros a: “minInclusive”, “maxInclusive”, “minExclusive”, “maxExclusive” en donde cualquier combinación es permitida. email: Es una subclase del validador “regex” y permite validar la sintaxis de una dirección de correo electrónico. url: A diferencia del validador “email”, este validador no es una subclase de “regex”. Al contrario, utiliza las características del constructor de java.net.URL para verificar la sintaxis de una dirección URL. date: Tiene los parámetros “min” y “max” para validar rangos de fechas. Recordar que el servidor recibe los parámetros en formato STRING. regex: Este validador acepta expresiones regulares (en sintaxis Java) y valida el valor ingresado contra la expresión dada. Si el campo a ser validado es obligatorio se debe usar el validador “requiredstring”. Este validador acepta parámetros “trim”, “caseSensitive” cuyo valor por defecto es TRUE. expression y fieldexpression: Ambos validadores toman expresiones OGNL en el parámetro “expression” para evaluarlo y determinar si hubo éxito o falla.
  • 44. 44 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Se recomienda realizar evaluaciones más complejas dentro del método “validate()” antes que en el archivo –validation.xml. Se puede combinar la validación en el código con el archivo XML simplemente invocando a: super.validate(). Ejemplo: 2.2.6: VALIDACIÓN USANDO ANOTACIONES También se puede utilizar las validaciones vía anotaciones en el código Java. Estos validadores requiere obligatoriamente el atributo “message” aun y cuando se especifique el atributo “key”. El parámetro “message” es utilizado como mensaje por defecto si es que la “key” no puede ser ubicada en el archivo de recursos. Adicionalmente, las expresiones OGNL están disponibles para las anotaciones. @Validation Se puede ubicar a nivel de método o a nivel de setter de una propiedad. Es una anotación que se utiliza sin parámetros. Solía ser obligatoria, pero ya no es necesario. @Validations Se aplica a nivel de método y permite agrupar las validaciones. Los grupos disponibles son: • requiredFields • requiredStrings • intRangeFields • stringLengthFields • regexFields • emails • urls • dateRangeFields • expressions • fieldExpressions • customValidators • visitorFields Esta anotación no es específica por método. Esto significa que todas las validaciones son ejecutadas para todos los métodos de la clase Action. Ejemplo:
  • 45. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 45 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES @SkipValidation Esta anotación sirve para marcar los métodos que deben ser excluídos de la validación. @RequiredFieldValidator Es equivalente al validador “required”. Es obligatorio el ingreso del atributo “message” aun y cuando se haya colocado un valor al atributo “key”. @IntRangeFieldValidator Funciona de la misma forma que el validador “int” utilizado en XML. Soporta los valores de “max” y “min”. Otros validadores El comportamiento es similar a los validadores usados en XML. La documentación del framework porporciona mayor detalle: • @DoubleRangeFieldValidator • @EmailValidator • @UrlValidator • @DateRangeFieldValidator • @StringRegexValidator • @ExpressionValidator • @FieldExpressionValidator • @ConversionErrorFieldValidator • @VisitorFieldValidator
  • 46. 46 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Resumen Recordar que Struts 2 es un framework bastante potente que permite agregar funcionalidad de tipo Ajax mediante la incorporación de algunos “tags” proporcionados por algún plug-in que trabaje con librerías de JavaScript como por ejemplo Dojo o JQuery. También, Struts 2 proporciona mecanismos para “bloquear” el envío duplicado de formularios de captura de datos mediante el empleo del tag <s:token>. Struts 2 permite definir validaciones para los campos de captura de los formularios. Si desea profundizar estos temas, puede consultar las siguientes páginas. http://struts.apache.org/2.2.1/docs/ajax-tags.html Aquí hallará la lista completa de tags Ajax en Struts 2 y ejemplos de uso. http://code.google.com/p/struts2-jquery/ En esta página, hallará el plug-in de jQuery para Struts 2 así como la documentación y ejemplos propocionados por Google Code. http://dojotoolkit.org/ En esta página, hallará documentación sobre el framework Dojo Toolkit. http://jquery.com/ En esta página, hallará documentación sobre el framework JavaScript JQuery.
  • 47. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 47 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES JAVA PERSISTENCE API ( JPA ) LOGRO DE LA UNIDAD DE APRENDIZAJE • Al término de la unidad, el alumno, construye una aplicación web de n-capas utilizando el modelo MVC y toda la funcionalidad provista por el framework Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel de modelo y la despliega dentro de un servidor de Aplicaciones Java EE compatible. TEMARIO Tema 1: Introducción a la API de Persistencia 1.1 Entidad 1.2 Metadata 1.3 EntityManager 1.4 Unidad de Persistencia 1.5 Operaciones básicas 1.6 Transacciones 1.7 Ciclo de Vida de una Entidad ACTIVIDADES PROPUESTAS • Los alumnos descargan y configuran un entorno de desarrollo con las librerías de JPA. • Los alumnos configuraran un servidor de aplicaciones para que ejecute aplicaciones que manejan JPA. • Los alumnos desarrollan aplicaciones Java Stand-Alone que trabajen con JPA para familiarizarse con el framework. UNIDAD DE APRENDIZAJE 2
  • 48. 48 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC TEMA 1: INTRODUCCIÓN A LA API DE PERSISTENCIA. La técnica que permite acortar las diferencias entre el modelo relacional y el modelo de objetos se conoce como ORM ( Mapeo Relacional a Objetos ). La idea básica se sustenta en que para mapear los conceptos de un modelo al otro ( o viceversa ) se requiere de un mediador que maneje de forma automática la transformación. La historia de JPA se origina en dos frameworks de persistencia bastante utilizados: en el lado propietario existía TopLink mientras que en el lado “open” estaba Hibernate. JPA es una especificación basada en el JSR 220 conocido como “Enterprise Java Bean 3.0” (http://jcp.org/en/jsr/detail?id=220 ). Al ser una especificación (o un conjunto de API’s) está sujeta a diversas implementaciones de diversos fabricantes. La idea principal es que sea un Framework ligero, basado en POJOs y pueda enfrentar desafíos de arquitectura e integración en aplicaciones empresariales. Algunas implementaciones de JPA : Hibernate http://www.hibernate.org/ TopLink http://www.oracle.com/technetwork/middleware/toplink/o verview/index.html OpenJPA http://openjpa.apache.org/ EclipseLink http://www.eclipse.org/eclipselink/ 1.1 ENTIDAD El concepto de “Entidad” fue introducido por Peter Chen en un documento llamado “The Entity-relationship model – Howard a unified view of data” publicado en “ACM Transactions on Database Systems” en el año de 19761 . En dicho documento se describía a las entidades como cosas que tenían “atributos” y “relaciones” con la expectativa de que dichos atributos y relaciones pudieran ser almacenados en la base de datos. En la actualidad dicha definición es vigente y dado que cualquier objeto dentro de una aplicación JPA puede ser una entidad, hay que definir las características que debe poseer una “Entidad”: • Persistencia : las entidades pueden ser manipuladas para recuperase en memoria o ser grabadas en un almacén de datos. 1 Una copia del documento se puede obtener en el enlace: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.123.1085&rep=rep1&type=pdf
  • 49. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 49 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES • Identidad: significa que las entidades tienen un identificador que permite emplearlas de manera inequívoca y diferenciarlas de otras instancias de la misma entidad. El identificador de la entidad es equivalente a la llave primaria de una tabla en la base de datos. • Transaccionalidad: Todas las operaciones ( insertar, modificar o eliminar ) deben realizarse dentro de un contexto transaccional debido a que se requiere de una transacción para que los cambios sean grabados en la base de datos. • Granularidad: Las entidades son objetos que pertenecen a un dominio de negocio, poseen un conjunto de estados y por tanto son relevantes para la aplicación (no se trata de objetos con tipo primitivo, sino de objetos más complejos). 1.2 METADATA Cada entidad tiene asociado una “metadata” que la describe. Dicha información puede estar almacenada dentro de la entidad Java o puede existir en un archivo externo: en ambos casos, esa información no se almacena en la base de datos. Existen dos maneras de especificar la metadata: • Usando Anotaciones • Usando XML Las anotaciones fueron introducidas en la versión JAVA EE 5 y permiten que la metadata esté incorporada dentro del código fuente Java. El uso de las anotaciones requiere que se importe el paquete “javax.persistence.*” dentro de la clase Java que representa a la Entidad. El uso de XML es una opción alternativa a las anotaciones, aunque su lectura puede resultar compleja para proyectos grandes. Un JavaBean cualquiera como el siguiente Se puede convertir en entidad, simplemente agregándole las anotaciones: @Entity @Id
  • 50. 50 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC No se debe olvidar que al ser un JavaBean, sigue las reglas de éste (con los getter/setter). 1.3 ENTITY MANAGER La mayoría de llamadas a las API’s de JPA se encapsulan dentro de lo que se conoce como “Entity Manager” y mediante el cual se puede alcanzar a la base de datos. Esta encapsulación es implementada dentro de una interface conocida como EntityManager que es la que ejecuta todo el trabajo de persistencia. Por tanto, una entidad mientras que no se trabaje con el Entity Manager es un objeto Java simple como cualquier otro. Cuando el Entity manager obtiene una referencia a una Entidad, se dice que dicha entidad está en estado “managed” El conjunto de entidades en estado “managed” dentro de un Entity Manager se conoce como “persistence context”. Los Entity Managers son configurados para trabajar con determinados tipos de objetos, bases de datos y son implementados por un proveedor (provider) conocido como “persistence provider”. En términos prácticos este provider es la implementación de la especificación JPA. Los Entity Managers se generan a partir de una factoría de tipo EntityManagerFactory, que genera una especie de plantilla para la persistencia, pero toma la configuración particular desde una unidad de persistencia conocida como “persistence unit”, la cual contiene la configuración implícita o explícita (con un nombre asociado ) para las entidades y para el Entity Manager. El gráfico2 resume las relaciones entre los conceptos mencionados: 2 FUENTE: “JPA 2: Mastering the Java Persistence API”, pág 23.
  • 51. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 51 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Un Entity Manager se obtiene de la siguiente forma: 1.4 UNIDAD DE PERSISTENCIA La configuración de una unidad de persistencia se escribe en un archivo llamado “persistence.xml”, el cual debe estar ubicado dentro del folder META-INF de un proyecto Java. Cada unidad de persistencia tiene un nombre, el cual es referenciado por la factoría al momento de pedirle que genere un EntityManager. Un archivo persistence.xml puede contener una o más unidades de persistencia, siendo cada una diferente de la otra. La estructura básica de un archivo persistence.xml es la siguiente: Nombre de la “persistence unit” Debe ser el mismo que aparece en el archivo persistence.xml Clase estática Variable con el Entity Manager cargado
  • 52. 52 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Debido a que es un archivo XML, debe tener un DTD: Luego viene la definición de la Unidad de persistencia, el proveedor y las clases Java definidas como entidades: El valor de RESOURCE_LOCAL indica que la conexión a la base de datos se realizará desde la misma aplicación ( No emplea Pool de conexiones ). Después se definen las propiedades de conexión a la base de datos: Nombre de la “persistence unit”
  • 53. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 53 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Finalmente se cierran los tags XML: Observe que las propiedades JDBC ( javax.persistence.jdbc.* ) han sido estandarizadas en JPA 2.0. En versiones anteriores de JPA, esas propiedades eran definidas por cada Persistence Provider. 1.5 OPERACIONES BÁSICAS Para aquellos desarrolladores acostumbrados al SQL en bases de datos relacionales, la equivalencia es sencilla en JPA: • SQL INSERT = Método Persist • SQL SELECT = Método Find ( o también puede usarse el SELECT JPQL ) • SQL UPDATE = Método Merge • SQL DELETE = Método Remove El “persist” de una entidad significa crear un objeto en memoria y luego almacenarlo en la base de datos para recuperarlo posteriormente. Como se ha mencionado, equivale a insertar uno o más registros en la base de datos. Si ocurre un error durante la ejecución del “persist”, se lanza la excepción PersistenceException, la cual debe será propagada, debiendo ser manejada por el programa. Se instancia el objeto Java Se cargan los valores de los atributos Se ejecuta el método “persist” mediante el EntityManager
  • 54. 54 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Para ubicar a una Entidad empleando el método “find”, generalmente se requiere sólo una línea de código: Si la entidad con la llave primara indicada no existe, el EntityManager devolverá NULL. La aplicación debe verificar el valor antes de usar la variable “emp” en el caso del ejemplo. Para eliminar una entidad se hace uso del método “remove”. Sin embargo se debe tener en consideración que para eliminar una entidad en JPA, primero debe colocarse en estado “managed”, es decir, debe cargarse al contexto de persistencia. Como se mencionó anteriormente, si la entidad no existe el EntityManager devolverá NULL, por lo que se debe evaluar dicha condición antes de invocar al método “remove”. Si se envía un valor de NULL al “remove”, JPA lanzará la excepción java.lang.IlegalArgumentException. Para actualizar atributos de una entidad, se emplea el método “merge”. Se requiere ubicar a la entidad antes de actualizarla: En este ejemplo se está actualizando el apellido del empleado con ID = 8. variable con el EntityManager cargado Clase de la Entidad a ser “ubicada” Evita hacer un “cast” Llave primaria de la Entidad Se requiere cargar la entidad
  • 55. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 55 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES 1.6 TRANSACCIONES El único método que puede estar fuera de una transacción es el “find” dado que no cambia atributos de las entidades. En una aplicación Java StandAlone (Java SE), se debe invocar el contexto transaccional de forma explícita, mientras que en una aplicación Java EE, se asume que el container proporciona dicho contexto transaccional. 1.7 CICLO DE VIDA DE UNA ENTIDAD JPA proporciona unos métodos denominados “callbacks” (listeners ) para ejecutar acciones en los diferentes estados que pueden suceder dentro del ciclo de vida de una entidad. Por ejemplo, imagine que desea actualizar una entidad, pero antes de hacerlo debe verificar que algunos datos estén presentes. En el gráfico se puede apreciar que una entidad no existe hasta que se instancia el objeto y se graba en la base de datos. De ahí pasa al estado “manejado” o “administrado” por el EntityManager y luego de ello se puede remover, actualizar, liberar ( “detach” ) o incluso volver a leer ( refrescar ). Se inicia una transacción Se inicia finaliza la transacción
  • 56. 56 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Las anotaciones que proporciona JPA para manejar los “Callbacks” son: • @PostLoad : Se ejecuta luego de un “refresh” a la entidad. • @PrePersist: Se ejecuta antes de insertar la entidad. • @PostPersist: Se ejecuta después de haber insertado la entidad. • @PreUpdate: Se ejecuta antes de un update a la entidad. • @PostUpdate: Se ejecuta después de un update a la entidad. • @PreRemove: Se ejecuta antes de eliminar la entidad en la base de datos. • @PostRemove: Se ejecuta después de haber eliminado a la entidad. Los métodos “callback” se pueden declarar dentro de la misma entidad o también en una clase Java separada. Por ejemplo, si de declaran dentro de la misma entidad:
  • 57. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 57 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES En cambio, si se prefiere emplear una clase Java externa, sería así: a) A la Entidad hay que agregarle la anotación @EntityListeners para indicar cual es la clase Java que contiene los métodos “callbacks”. b) Se debe crear una clase Java y escribir los métodos que se requiere manejar (con las anotaciones del caso).
  • 58. 58 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Resumen Recordar que JPA es una especificación, por tanto, tiene muchas implementaciones. El desarrollador debe seleccionar una en particular, siendo las más conocidas: Open JPA, TopLink, EclipseLink e Hibernate. Diferenciar entre Entidades y Clases Java Recordar la ubicación del archivo persistence.xml que debe ir siempre dentro del folder META-INF. Recordar para que sirve el EntityManager y la persistence-unit Las operaciones básicas sobre una Entidad: find, persist, merge, remove Si desea saber más acerca de estos temas, puede consultar las siguientes páginas: http://www.eclipse.org/eclipselink/jpa.php Aquí hallará una referencia completa a la implementación EclipseLink. http://www.agiledata.org/essays/mappingObjects.html Aquí hallará información útil sobre Entidades JPA. También puede consultar el libro “Pro JPA 2 : Mastering the Java API Persistence” Capítulos 1,2,4, y 6.
  • 59. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 59 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES JAVA PERSISTENCE API ( JPA ) LOGRO DE LA UNIDAD DE APRENDIZAJE • Al término de la unidad, el alumno, construye una aplicación web de n-capas utilizando el modelo MVC y toda la funcionalidad provista por el framework Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel de modelo y la despliega dentro de un servidor de Aplicaciones Java EE compatible. TEMARIO Tema 2: OR-Mapping con JPA 2.1. Anotaciones 2.2. Manejo de la Llave Primaria 2.3. Generación de la Llave Primaria 2.4. Llave Primaria Compuesta 2.5. Objetos Embebidos ACTIVIDADES PROPUESTAS • Los alumnos escriben clases Java, las convierten en Entidades JPA y trabajan con tablas relacionales. • Lós alumnos desarrollan aplicaciones Java stand-alone haciendo uso de entidades JPA. UNIDAD DE APRENDIZAJE 2
  • 60. 60 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC TEMA 2: OR-MAPPING CON JPA 2.1 ANOTACIONES Las anotaciones pueden clasificarse en dos grupos: • Anotaciones lógicas describen el modelo de entidades desde el punto de vista del modelamiento orientado a objetos. Constituyen una especie de metadata del modelo. • Anotaciones físicas están relacionadas con el modelo en la base de datos (modelo físico) y tienen que ver con tablas, columnas, etc. Las anotaciones dentro de una clase Java se pueden colocar a nivel de atributos o a nivel de métodos. Si se colocan a nivel de atributos se denomina “Field Access” mientras que si se coloca a nivel de métodos se denomina “Property Access”. Es equivalente a: En la especificación de JPA 2.0 se introduce la anotación @Access permite combinar los dos modos presentados en el ejemplo. Esta anotación permite sobre escribir el modo de acceso por defecto, aunque no es muy usual hacerlo. Para definir una entidad basta con emplear la anotación @Entity y la anotación @Id. Anotación de tipo “Field Access” Anotación de tipo “Property Access” NOTA: Siempre va en el GETTER Atributos de la clase
  • 61. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 61 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Anotación @Table Por defecto no es necesario incluir ninguna anotación para referenciar a una tabla. JPA asume que la tabla se llama igual que la clase Java en donde se define la entidad. Sin embargo, si se desea especificar un nombre de tabla en particular para asociarlo con la entidad, es preciso utilizar la anotación @Table con el parámetro “name” respectivo. Se puede indicar además, el esquema de base de datos con el atributo “schema” (para aquellos motores de base de datos que lo soporten): Se debe tener cuidado con el uso de mayúsculas y minúsculas, pues muchos manejadores de bases de datos no son sensibles a esto. Anotación @Basic Cuando se “persiste” una propiedad de una entidad, el “persistente provider” verifica que el tipo de dato corresponda a un tipo soportado y trata de pasarlo hacia la base de datos vía el driver JDBC. Los tipos de datos soportados son: Tipos primitivos byte, int, short, long, boolean, char, float double Clases que encapsulan a tipos primitivos Byte, Integer, Short, Long, Boolean, Character, Float, Double Arreglos de bytes y caracteres byte[], Byte[], char[], Character[] Números java.math.BigInteger, java.math.BigDecimal Cadenas de caracteres java.lang.String
  • 62. 62 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Tipos de datos que manejan fechas Java java.util.Date, java.util.Calendar Tipos de datos que manejan fecha JDBC java.sql.Date, java.sql.Time, java.sql.Timestamp Tipos enumerados Cualquiera Objetos serializables Cualquiera Se debe tener cuidado con el comportamiento del driver JDBC cuando los tipos de datos no coinciden entre lo que se define en la entidad y lo que soporta la base de datos, pues el driver intentará ejecutar la mejor conversión posible. La anotación @Basic (que es opcional) se utiliza para indicar de forma explícita que dicho atributo debe ser almacenado en la base de datos. Anotación @Transient Se emplea para marcar aquellos atributos de la entidad que NO deben ser guardados en la base de datos. Anotación @Column Es una anotación de tipo físico, pues indica las características físicas de la columna en la base de datos. Si no se especifica para un atributo determinado marcado como persistente, JPA asume que la columna se llama igual que dicho atributo. En cambio, si la columna tiene un nombre diferente, se deberá especificar con el uso de la anotación @Column.
  • 63. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 63 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Los elementos que acompañan a la anotación @Column son: Elemento Descripción Valor por defecto String columnDefinition (Opcional) Es el fragmento de SQL utlizado para generar el DDL de la columna (depende del manejador de base de datos) “” boolean insertable (Opcional) Indica si la columna ser incluirá dentro de una sentencia SQL INSERT generada por el Persistence Provider. true int length (Opcional) Indica la longitud de la columna en la tabla y funciona únicamente cuando la columna es un String o cadena de caracteres. 255 String name (Opcional) Indica el nombre de la columna. POr defecto se asume que la columna se llama igual que el atributo de la entidad. “” boolean nullable (Opcional) Indica si la columna permite valores nulos. true int precision (Opcional) Indica la precisión para una columna numérica ( válido solo para columnas decimales ). 0 int scale (Opcional) Indica la escala para una columna numérica ( válido solo para columnas decimales ). 0 String table (Opcional) Indica el nombre de la tabla en donde se asocial la columna. “” boolean unique (Opcional) Se emplea cuando la clave única corresponde a una sóla columna. false boolean updatable (Opcional) Indica si la columna ser incluirá dentro de una sentencia SQL UPDATE generada por el Persistence Provider. true Ejemplo 1: Ejemplo 2: Anotación @Lob Para el manejo de objetos binarios (imágenes o archivos generalmente) se requieren accesos especiales en el driver JDBC para efectuar conversiones entre el objeto Java y la columna en la tabla de la base de datos. La anotación @Lob sirve para indicar que el atributo de dicha entidad requiere efectuar las conversiones vía JDBC. Ahora bien, los campos LOB (acrónimo de Large Object) se pueden clasificar de dos maneras, siendo el manejo de cada manera un tanto diferente:
  • 64. 64 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Si el objeto es … El tipo java a usar es … Character Large Objets ( CLOB ) • char[] • Character[] • String Binary Large Objects ( BLOB ) • byte[] • Byte[] • tipos serializables En ambos casos, el driver JDBC es responsable de hacer las conversiones entre el objeto Java y la base de datos. Ejemplo: Anotación @Temporal Sirve para especificar tipos de datos basados en el tiempo. Estos tipos de datos se pueden clasificar en dos ramas: los que vienen del paquete java.sql y los que viene del paquete java.util. En el paquete java.sql los tipos se trabajan directamente: • java.sql.Date • java.sql.Time • java.sql.Timestamp En cambio, en el paquete java.util: • java.util.Date • java.util.Calendar Anotación Tipo de dato
  • 65. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 65 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Se debe especificar la anotación @Temporal y además especificar el atributo “TemporalType” con uno de los tres valores que representan a cada uno de los tipos java.sql (DATE, TIME o TIMESTAMP). Ejemplo: 2.2 MANEJO DE LA LLAVE PRIMARIA Cada Entidad debe tener una llave primaria. La anotación empleada es @Id sobre el atributo que contiene la llave. Adicionalmente se puede usar @Column para asociar al atributo con la columna en la tabla. Una llave primaria se asume que es “insertable”, pero no puede ser “nullable” o “updatable” por lo que se debe tener cuidado de no sobre escribir esos atributos salvo excepciones muy específicas (cuando se manejan relaciones). Los tipos de datos soportados para una llave primaria son: Tipos primitivos byte, int, short, long, char Clases de tipos primitives Byte, Integer, Short, Long , Character Cadenas de caracteres java.lang.String Números grandes java.match.BigInteger Tipos basados en tiempo java.util.Date, java.sql.Date 2.3 GENERACIÓN DE LA LLAVE PRIMARIA También se conoce como “Generación del ID” y se realiza mediante la anotación @GeneratedValue. En base a dicha anotación, el “Persistence Provider” genera el ID para cada entidad, y lo inserta en la columna respectiva. Se debe tener en cuenta que dependiendo de la estrategia de generación del ID, el valor obtenido puede que no esté disponible hasta que se ejecute un “flush” o un “commit” a la transacción. Anotación Equivalencia JDBCTipo de dato java.util.Date
  • 66. 66 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Existen cuatro estrategias posibles (que son un tipo enumerado de “GenerationType”): • AUTO • TABLE • SEQUENCE • IDENTITY ESTRATEGIA “GenerationType.AUTO” Este tipo de estrategia delega en el “Persistence Provider” la selección de la mejor forma de generación de los “ID”. Cualquiera sea la la forma elegida por el provider, se confiará en los recursos de la base de datos para la obtención de los ID’s. En el caso particular de EclipseLink con MySQL, la estrategia AUTO emplea una tabla denominada “sequence”. Ejemplo: ESTRATEGIA “GenerationType.TABLE” Esta estrategia es la más flexible y portable, pues permite que la aplicación genere ID’s diferentes de acuerdo a las necesidades. La tabla requiere de dos columnas, una conteniendo el identificador para generar la secuencia y la otra columna contiene el último valor generado. Cada fila de la tabla es un generador diferente para los ID’s. Un ejemplo sencillo es el siguiente:
  • 67. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 67 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Dado que no se ha especificado el nombre de un “generador” ni el nombre de una tabla, el Persistence provider seleccionará sus propios valores. Lo más común es que busque (la tabla debe existir en la base de datos) una tabla como la indicada en la figura. ¿Qué sucede si se desea especificar una tabla en particular ? Se debe emplear la anotación @TableGenerator. Ejemplo: El atributo “allocationSize” indica el incremento en la generación del ID (para el caso del ejemplo va de uno en uno ). Por defecto el incremento es 50.
  • 68. 68 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC ESTRATEGIA “GenerationType.SEQUENCE” Esta estrategia depende de las capacidades de la base de datos para manejar objetos de tipo “secuencia” (caso de Oracle). Al igual que en la estrategia TABLE, basta con escribir la anotación para que el “Persistence Provider” seleccione la mejor secuencia dentro de la base de datos. Ejemplo: Si se desea especificar una secuencia en particular, debe indicarse el “generator” y la anotación @SequenceGenerator. Se debe considerar que la secuencia debe existir previamente en la base de datos (salvo que la opción de generación de DDL esté habilitada en nuestra aplicación). Ejemplo (la secuencia es para Oracle): Estrategia
  • 69. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 69 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES ESTRATEGIA “GenerationType.IDENTITY” Esta estrategia aprovecha las facilidades de la bases de datos para utilizar columnas de tipo “autoincremento”. Sin embargo es menos eficiente porque el identificador generado no está disponible hasta después que ocurra el INSERT. No requiere una anotación para el “generador” dado que el campo autoincremental es parte de la definición de la tabla que corresponde a la entidad. Ejemplo: 2.4 LLAVE PRIMARIA COMPUESTA En algunas situaciones, en donde se requiere que la llave primaria de una entidad esté compuesta de múltiples atributos. JPA proporciona dos formas de soportar esta necesidad mediante las anotaciones: • @IdClass • @EmbeddedId Se debe tener en cuenta que: a) En ambos casos se requiere de una clase Java externa que sea la que maneje los atributos de la llave primaria. b) La clase Java que maneja los atributos de la llave primaria, debe implementar los métodos equals() y hashCode() con el fin que el Persistence Manager pueda almacenar e identificar las entidades. c) La clase Java que representa a la llave primaria debe ser pública, implementar a la interface Serializable y tener un constructor sin argumento. Ejemplo: Dada la siguiente tabla “tbmatricula” con una llave primaria compuesta Estrategia
  • 70. 70 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC La Entidad y la clase Java que maneja la llave primaria pueden representarse así (no olvidar que se debe generar los métodos getter/setter en ambas clases Java): Observe que la anotación @IdClass especifica el nombre de la clase Java que maneja la llave primaria.
  • 71. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 71 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Observe también que la clase Java que maneja la llave primaria no posee anotaciones. Sin embargo, debe implementar los métodos nombrados líneas arriba: El método equals() lo que hace es comparar uno a uno los atributos de la llave primaria contra los atributos de otra entidad para verificar que no se trate de la misma entidad. El método hashCode() lo que hace es devolver un código “hash” de los valores de la llave primaria. Para consultar una entidad con una llave primaria compuesta sólo se requiere generar una instancia de la clase que maneja la llave primaria, cargarle los valores necesarios y pasar dicha variable al EntityManager. Ejemplo: 2.5 OBJETOS EMBEBIDOS Un objeto embebido es aquel que es dependiente de una entidad: no tiene identidad por sí mismo. Entender este concepto es muy útil para el manejo de relaciones entre entidades.
  • 72. 72 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Si bien, a nivel de Java, los objetos embebidos se administran de forma separada, a nivel de base de datos, la entidad y la clase embebida se almacenan sobre el mismo registro de la tabla. Por ejemplo, en el siguiente gráfico se tiene la entidad “CUSTOMER” y la tabla “tbcustomer”. Observe que los datos de la dirección pueden constituir una clase separada: Si se convierte la dirección en una clase “Embebida” quedaría así: Anotación @Embedded Anotación @Embeddable
  • 73. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 73 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Se debe observar que: a) La Entidad declara un atributo con el tipo de dato de la clase “Address” y a este atributo le coloca la anotación “@Embedded” para indicar que esa clase es “embebida”. b) La clase “Address” NO tiene anotaciones que indiquen que es una entidad. Unicamente tiene la anotación “@Embeddable” para indicar que hay “otra” clase que la incluye (o que la referencia). c) Ambas clases tienen sus getter/setter. d) Ambas clases deben definirse en el archivo persistente.xml. e) Finalmente, es importante saber que sólo se puede ejecutar queries sobre la clase marcada como “Entidad”.
  • 74. 74 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Resumen Una clase Java se convierte en Entidad al agregar la anotación @Entity. Además, existen otras anotaciones que permiten el mapeo contra columnas de la tabla en la base de datos. Existen cuatro maneras de generar la secuencias para ID’s: • AUTO • TABLE • SEQUENCE • IDENTITY Recordar el uso de la anotación @Temporal para tipos de datos que manejan tiempo. Revise el libro :“Pro JPA 2 : Mastering the Java API Persistence” Capítulo 4 Si desea saber más acerca de estos temas, puede consultar las siguientes páginas. http://www.objectdb.com/api/java/jpa/annotations/orm Aquí hallará mayor información respecto al tema. ACTIVIDAD RECOMENDADA • Buscar mayor información sobre la anotación @Access • Investigar acerca de tipos enumerados que se manejan con @Enumerated
  • 75. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 75 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES JAVA PERSISTENCE API ( JPA ) LOGRO DE LA UNIDAD DE APRENDIZAJE • Al término de la unidad, el alumno, construye una aplicación web de n-capas utilizando el modelo MVC y toda la funcionalidad provista por el framework Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel de modelo y la despliega dentro de un servidor de Aplicaciones Java EE compatible. TEMARIO Tema 3: Relaciones entre entidades 3.1. Conceptos básicos 3.2. Many To One 3.3. One to One 3.4. Bidireccionalidad de la relación One-to-One 3.5. One to Many 3.6. Many to Many 3.7. Opciones de Fetch ACTIVIDADES PROPUESTAS • Los alumnos generan Entidades JPA y definen relaciones entre ellas. • Lós alumnos desarrollan aplicaciones Java haciendo uso de las entidades JPA y sus relaciones. UNIDAD DE APRENDIZAJE 2
  • 76. 76 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC TEMA 3: RELACIONES ENTRE ENTIDADES 3.1 CONCEPTOS BÁSICOS ROLES Las relaciones entre entidades tienen tres diferentes perspectivas: a) La primera es el punto de vista desde un lado de la relación. b) La segunda en el punto de vista desde el otro lado de la relación. c) La tercera es la perspectiva global que mira ambos lados de la relación. Estos “lados” son conocidos como “roles”. Tal es así que en cada relación hay dos entidades que se relacionan mutuamente de tal manera que cada una cumple un rol dentro de la relación. Es más, una entidad puede jugar muchos roles dentro de un modelo. DIRECCIONALIDAD Existen maneras de crear, remover y actualizar las relaciones para darles mantenimiento. Si una entidad tiene relación con otra, existirá un atributo que sirve para identificar la relación y referirse a la entidad relacionada identificando así el rol que juega en la relación. Cuando las entidades se referencian mutuamente se dice que la relación es bi- direccional. Ejemplo: El empleado sabe en que Proyecto trabaja y el Proyecto conoce quiénes son sus miembros (las flechas indican el sentido de la dirección). Si una entidad apunta únicamente a otra, la relación es unidireccional. El empleado conoce su Dirección, pero la inversa no necesariamente es cierta ( la flecha indica el sentido de la relación). Ahora bien, la relación Bi-direccional puede ser descompuesta en dos relaciones uni- direccionales. Cada relación tendrá un origen (“source” o rol de referencia) y un
  • 77. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 77 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES destino ( “target” o rol referido ). Se debe tener en cuenta esto, pues el origen y destino varían según la perspectiva que estemos usando para analizar la relación. CARDINALIDAD La cardinalidad de una relación sirve para determinar cuantas instancias de una entidad existen en cada lado de una misma relación. Cada rol dentro de la relación tendrá su propia cardinalidad, la cual indicará cuando exista una sola o muchas instancias. Por ejemplo, muchos empleados pueden trabajar en el mismo departamento (se muestra una relación de muchos a uno): ORDINALIDAD Un rol puede especificarse de forma más detallada para indicar si puede o no estar presente en una relación. La ordinalidad sirve para indicar si la entidad “target” necesita ser especificada cuando la entidad “source” es creada. Debido a que la ordinalidad es un valor lógico (verdadero o falso) es más práctico referirse a ella como “opcionalidad” de la relación. MAPEANDO LA RELACIÓN ENTRE ENTIDADES Existen básicamente dos formas de asociación: • Las basadas en valores simples. • Las basadas en colecciones de valores. Dentro de esas formas de asociación, existen cuatro formas de “mapeo”: • Relación One-To-One (valores simples) • Relación Many-To-One (valores simples) • Relación One-To-Many (colecciones de valores) • Relación Many-To-Many (colecciones de valores)
  • 78. 78 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC A nivel de Base de Datos, la relación entre entidades significa que una tabla referencia a otra tabla: aparece el concepto de “Foreign Key” para indicar aquellos campos de una tabla que hacen referencia a la “Primary Key” de otra tabla. A nivel de JPA las columnas que forman la “Foreign Key” se conocen como “Join Columns” y emplean la anotación @JoinColumn para indicar dicha funcionalidad. 3.2 RELACIÓN MANY-TO-ONE Es la relación más típica que podemos encontrar en el mundo real. En UML se requiere que la clase “source” tenga un atributo del tipo de la clase ”target” para poder navegar hacia ella. Ejemplo: Si varios Empleados pueden trabajar en un Departamento, la relación de entidades se puede modela como se muestra a continuación: Tenga en cuenta que: a) La clase “source” tienen un atributo que corresponde al tipo de la clase “target” (observe el atributo “departamento”). b) A dicho atributo se le debe colocar la anotación @ManyToOne. Ahora falta llevar la relación al modelo de base de datos siguiente:
  • 79. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 79 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Las tablas físicas están relacionadas mediante la columna “DPTO_ID” en la tabla “tbempleado” que apunta a la columna “DEPT_ID” en la tabla “tbdepartamento”. Entonces, la “Join Column” de la relación es la columna “DPTO_ID”. El lado que tiene a la “Join Column” se conoce como el “OWNER SIDE” de la relación, mientras que el lado que no tiene a la “Join Column” se conoce como “INVERSE SIDE”. En este ejemplo, el lado OWNER es la tabla “tbempleado” y el lado INVERSO es la tabla “tbdepartamento”. La anotación @JoinColumn siempre se debe colocar en el lado “OWNER” de la relación. La entidad “Employee” debe quedar así (observe la anotación @JoinColumn):
  • 80. 80 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Si no se coloca la anotación @JoinColumn, JPA asume el nombre por defecto, el cual está formado por el nombre del atributo en la entidad owner seguido de un guión bajo (“_” ) y concatenado con el nombre de la columna PK en la tabla inversa. 3.3 RELACIÓN ONE-TO-ONE La relación “Uno a Uno” es casi igual a la relación “Muchos a Uno” con la sola excepción que una instancia de la entidad “source” puede apuntar a una única instancia de la entidad “target”. Estrictamente hablando, eso significa que la entidad “target” no puede ser compartida por otras instancias de la entidad “source”. A nivel de base de datos esta relación implica un criterio de “unicidad” o llave única en la “Foreign Key” de la entidad “source”. Obviamente, se requiere definir la relación en la Entidad “Employee”: para ello se hace uso de la anotación @OneToOne y también se requiere usar @JoinColumn (en este caso, la columna de Join es “PARKING_ID”). La entidad “Employee” quedará así:
  • 81. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 81 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES 3.4 BIDIRECCIONALIDAD DE LA RELACIÓN ONE-TO-ONE En algunas situaciones se requiere considerar la relación inversa entre las entidades, también conocida como bidireccionalidad de la relación. La decisión es un criterio de modelamiento, más no una obligación a nivel de programación. Para lograr esto, se requiere que la entidad “target” tenga un atributo de la clase correspondiente a la entidad “source”. Dicho atributo debe tener la anotación @OneToOne con el elemento “mappedBy” que indique cual es el atributo de la clase “source” que contiene la relación y apunta a la entidad “target”. Ejemplo: en el caso de la entidad “ParkingSpace” (“es el “target” de la relación) se tendría el siguiente atributo: Y en el caso de la entidad “Employee” ( que es el “owner” de la relación) tendríamos: Debe tenerse en cuenta dos reglas:
  • 82. 82 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC a) La anotación @JoinColumn se coloca en la entidad que mapea a la tabla que contiene la columna de join ( o a la entidad que es “owner” de la relación ). b) El elemento “mappedBy” debe colocarse a la anotación @OneToOne de la entidad “inversa” o “target” de la relación. 3.5 RELACIÓN ONE-TO-MANY Cuando una entidad se asocia con una “colección” de otras entidades estamos ante una relación de “uno a muchos”. En el ejemplo del Empleado vs. el Departamento, la relación es bidireccional por naturaleza. En una relación bidireccional, siempre existen dos “mapeos”: uno por cada relación. A nivel de base de datos, las tablas siguen siendo las mismas. Y a nivel de entidades, la entidad “Employee” es la misma. Como se tiene que implementar el lado inverso de la relación entre Empleado y Departamento, se debe modificar la entidad “Department” para agregar la relación inversa “One-To-Many”: se debe “mapear” una colección de entidades “Empleado” usando la anotación @OneToMany. Adicionalmente, como éste es el lado inverso de la relación, se debe usar el atributo “mappedBy” para indicar cual es el atributo dentro de la entidad “Employee” que contiene la llave de la relación:
  • 83. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 83 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES NOTA: En este caso se está usando una colección indicado el tipo de los elementos que almacena dicha colección: Collection<Type>. Esto genera una dependencia al compilar por lo que no es recomendable. La otra forma de colocar la relación es especificando el atributo “targetEntity” sin especificar el tipo de dato contenido en la colección: Esquemáticamente las dos relaciones se ven así:
  • 84. 84 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Es importante tener en cuenta que: a) El lado “many-to-one” siempre es el lado “owner” de la relación. En consecuencia, la anotación @JoinColumn debe estar en dicho lado. b) El lado “one-to-many” es el lado “inverso”, por lo que el elemento “mappedBy” debe ser utilizado en este lado. c) Si no se especifica el “mappedBy”, JPA considera que es una relación unidireccional de tipo one-to-many por lo que requiere el uso de una tabla de Join. Tener en cuenta que esto puede ocasionar errores al desarrollar aplicaciones. 3.6 RELACIÓN MANY-TO-MANY Cuando una o más entidades se asocian con una “colección” de otras entidades y dichas entidades tienen relaciones sobrepuestas con las mismas entidades “target”, se dice que estamos frente a una relación de tipo “Mucho-a-Muchos”. Por ejemplo: Un “Empleado” pueden trabajar en múltiples “Proyectos” y cada “Proyecto” puede tener a muchos “Empleados”. De los ejemplos anteriores podemos manejar las siguientes entidades:
  • 85. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 85 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES La relación “Muchos-a-Muchos” se puede expresar en las dos entidades (“source” y “target”) utilizando la anotación @ManyToMany. Teniendo en cuenta que: a) Cuando la relación “Many-To-Many” es bidireccional, ambos lados de la relación deben tener la anotación @ManyToMany. b) No existen columnas de join en cada lado de la relación: la única forma de implementar ésta relación es utilizando una tabla de join, por lo que no existe manera de determinar CUAL es el lado “owner” de la relación, en consecuencia, se debe asumir que uno de los lados es el “owner”. c) Al igual que en las relaciones bidireccionales anteriormente tratadas, el lado que no sea “owner” debe utilizar el “mapeddBy”, en caso se omita éste elemento, JPA deducirá que se trata de dos relaciones unidireccionales separadas. En el ejemplo, la anotación @ManyToMany debe colocarse en ambas entidades:
  • 86. 86 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC El modelo de base de datos es: A nivel de base de datos, una “Join Table” consiste simplemente de dos “Foreign Key” o columnas de join que referencian (cada una) a un lado de la relación. La anotación @JoinTable se usa para configurar la tabla de join de la relación: a) Cada columna de Join se distingue dependiendo del papel dentro de la relación: lado owner o lado inverso. b) La columna de Join que pertenece al lado “owner” se describe usando el elemento “joinColumns”. c) La columna de Join que pertenece al lado “inverse” se describe usando el elemento “inverseJoinColumns”. En el ejemplo, falta indicar la JoinTable de la siguiente forma (asumiendo que Employee es el owner de la relación). Tenga en cuenta que el elemento “name” dentro de @JoinColumn especifica el nombre de la columna en la tabla de Join, mientras que el elemento
  • 87. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 87 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES “referencedColumnName” indica la columna que es “Primary Key” en la tabla que se encuentra al extremo de la relación (sea owner o inversa). Y en el lado inverso de la relación se pone el elemento “mappedBy”: 3.7 OPCIONES DE FETCH Las entidades y sus atributos pueden ser cargados de dos formas: • LAZY: Cuando se cargan de forma “perezosa”, es decir, se cargan en el momento en que se requieren. • EAGER: Cuando se cargan de forma “proactiva”, es decir, al momento de cargar la entidad “owner” de la relación. En términos de JPA, se usa el elemento “fetch” acompañando a la anotación de la relación e indicando el valor de FetchType.LAZY o FetchType.EAGER . En una relación de valores simples el FetchType por defecto es EAGER. En una relación de colecciones de valores, el FetchType por defecto es LAZY. En una relación bidireccional, el FetchType puede ser EAGER en un sentido y LAZY en el otro dependiendo del tipo de navegación que se desea.
  • 88. 88 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Resumen Recordar que en JPA, existen cuatro tipos de relaciones entre entidades: • One To One • One To Many • Many To One • Many To Many Revise el libro :“Pro JPA 2 : Mastering the Java API Persistence” Capítulo 4 Si desea profundizar más acerca de este tema, puede consultar el siguiente enlace: http://www.javaworld.com/javaworld/jw-01-2008/jw-01-jpa2.html Aquí hallará un ejemplo desarrollado del tema.
  • 89. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 89 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES JAVA PERSISTENCE API ( JPA ) LOGRO DE LA UNIDAD DE APRENDIZAJE • Al término de la unidad, el alumno, construye una aplicación web de n-capas utilizando el modelo MVC y toda la funcionalidad provista por el framework Struts-2 a nivel de vista-controlador y por JPA (Java Persistence API) a nivel de modelo y la despliega dentro de un servidor de Aplicaciones Java EE compatible. TEMARIO Tema 4: Lenguaje de Consultas JPQL 4.1. Introducción a JP-QL 4.2. Consultas dinámicas 4.3. Consultas nombradas 4.4. Uso de parámetros 4.5 Ejecucion de Queries 4.6 Sintaxis de JPQL ACTIVIDADES PROPUESTAS • Los alumnos desarrollan aplicaciones web que mediante el empleo de JPQL naveguen en la base de datos utilizando el modelo de entidades JPA y sus relaciones. UNIDAD DE APRENDIZAJE 2
  • 90. 90 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC TEMA 4: LENGUAJE DE CONSULTAS JPQL JPA soporta dos formas para expresar consultas que recuperan entidades desde una base de datos: • El lenguaje de consultas (queries), conocido como Java Persistence Query language ( JPQL ), es un lenguaje independiente del manejador de base de datos que trabaja con entidades en lugar de usar tablas. • La API de criterios, que sirve para construir consultas basadas en objetos Java en lugar de escribir los queries en strings. 4.1 INTRODUCCIÓN A JPQL Los antecedentes de JPQL se pueden encontrar en la especificación de EJB 2.0 con el lenguaje EJB-QL en el cual se introdujo una forma de navegar entre los Beans y sus relaciones, así como filtros y funciones agregadas. Los queries operan dentro de una unidad de persistencia y pertenecen a una de las siguientes clasificaciones: a) SELECT, son queries que recuperan una o más entidades, filtrando los resultados si fuera necesario. b) AGGREGATE, los queries de este tipo son variaciones de los queries del tipo SELECT, con la salvedad que agrupan resultados para producir información sumarizada (de ahí la necesidad de usar la cláusula GROUP BY ). c) UPDATE, son queries que se emplean para actualizar un conjunto de entidades.
  • 91. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 91 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES d) DELETE, son queries que se utilizan para remover un conjunto de entidades. Al utilizar los queries se debe considerar que las entidades son referenciadas por su nombre. Si una entidad no tiene asignado un nombre de forma explícita, JPA asume el nombre de la clase como nombre por defecto: este nombre se conoce como “abstract schema name” de la entidad dentro del contexto del query. También, es importante resaltar que para los queries es indiferente el uso de mayúsculas y minúsculas salvo en dos casos: nombre de entidades y nombres de atributos de cada entidad. Dada una entidad como la siguiente ( entidad “Employee” ): El query más sencillo que se pueden ejecutar es: Observe que la notación es muy similar al SQL normal, pero con ligeras diferencias:
  • 92. 92 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC a) En JPQL, lo que sigue a la cláusula “FROM” es el nombre de la entidad, es decir, no se coloca el nombre de la tabla (recordar que la Entidad “mapea” a una tabla). b) En JPQL, es obligatorio que las entidades sean “calificadas” con un “alias”: en el caso del ejemplo, el alias es “e”. Este “alias” se conoce como “variable de identificación”. c) El alias indicará que el resultado será uno o más entidades del tipo correspondiente a la entidad. d) El tipo de resultado de un Query no puede ser una Colección. Debe ser un tipo simple o una Entidad. A partir del uso del “alias” para la entidad, se puede utilizar la notación “dot” (el punto “.”) para referenciar campos persistentes de la entidad. Por ejemplo, si queremos seleccionar únicamente los nombres de los empleados sería así: En este caso, como el campo “nombre” es un String, el resultado del query devolverá uno o más Strings. De la misma forma puede trabajarse para cualquier otro atributo, sea una lista, colección o campos simples. El seleccionar algunos campos de la entidad (al igual que en SQL) recibe el nombre de “proyección”. Se debe tener en cuenta su uso si es que se van a descartar (no usar) varios atributos de la entidad al momento de generar reportes (dada la sobrecarga que se genera en el framework JPA ). En el siguiente ejemplo, se puede seleccionar una entidad que no está en la cláusula FROM: Observe que “departamento” es una campo de la entidad “Employee”, pero a la vez es una Entidad (dada la relación establecida @ManyToOne). Por tanto, el resultado de ese query será una entidad “Department” obtenida a partir de la relación. FILTROS Al igual que en SQL, se puede filtrar los resultados a obtener utilizando la cláusula WHERE y la notación “dot”. JPQL incluye operadores como IN, LIKE y BETWEEN, funciones como SUBSTRING y LENGTH además de soportar subqueries. Ejemplo:
  • 93. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 93 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES En este ejemplo, el filtro lo constituye el atributo “nombre” de la entidad “Department” que está vinculada con la entidad “Employee”. JOIN ENTRE ENTIDADES Al igual que en SQL, si se desea navegar entre las relaciones de las entidades y retornar elementos de la colección, se debe ejecutar un JOIN entre entidades. Se puede ejecutar el JOIN al más puro estilo del tradicional SQL indicando los criterios de JOIN en la cláusula WHERE. Sin embargo, JPQL proporciona la facilidad de especificar el JOIN dentro de la cláusula FROM con la finalidad de expresar el JOIN en términos de la relación existente entre las entidades: JPA se encargará de armar la sentencia SQL equivalente. Un JOIN ocurre si se cumple cualquiera de las siguientes condiciones en el SELECT: 1) Dos o más declaraciones de variables son listadas en la cláusula FROM y aparecen en la cláusula SELECT. 2) El operador JOIN es empleado para extender a una variable de identificación usando “expression path”. 3) Un “path expression” en cualquier parte del query navega a través de un campo de asociación en la misma o en otra entidad. 4) Una o más condiciones WHERE comparan atributos de variables de identificación diferentes. Se debe tener en cuenta que ante la ausencia de condiciones de JOIN entre entitades, se generará un producto cartesiano entre la primera entidad y cada ocurrencia de la segunda entidad. INNER JOIN Un “inner join” entre dos entidades se puede especificar de cualquiera de la maneras indicadas anteriormente. Sin embargo, la forma preferida es mediante el uso del operador JOIN en la cláusula FROM. La sintaxis básica es: [INNER] JOIN <path_expression> [AS] <identifier>
  • 94. 94 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Ejemplo 1: se asume que “phones” contiene una relación JPA entre “Employee” y “Phone” Ejemplo 2: múltiples Joins ( los joins se interpretan de izquierda a derecha desde el FROM ) OUTER JOIN Un “outter join” entre dos entidades produce un ámbito en el cual solo un lado de la relación es requerido para completar el resultado. Por ejemplo, un outer join entre “Empleado” y “Departamento” mostrará todos los empleados y los departamentos a los que han sido asignados, pero con la salvedad que el “Departamento” será retornado únicamente si existe dentro de la relación ( a diferencia de un inner join ). Su sintaxis es la siguiente: LEFT [OUTER] JOIN <path_expression> [AS] <identifier> Ejemplo 1: FETCH JOIN Este tipo de Join sirve para ayudar a los programadores a optimizar los accesos a la base de datos. Permite que los queries especifiquen una o más relaciones que deben ser navegadas y pre-cargadas por el mecanismo de recuperación de datos de tal forma que no se ejecuten “lazy load” en tiempo de ejecución. En otras palabras, reduce la cantidad de accesos a la base de datos. Ejemplo:
  • 95. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 95 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES QUERIES AGREGADOS La sintaxis es muy similar a SQL: se requiere el uso del agrupamiento con GROUP BY Es opcional el uso del filtro mediante la cláusula HAVING. JPA incluye cinco funciones agregadas: • AVG : Promedio aritmético. • COUNT : Cantidad de repeticiones. • MIN: Menor valor. • MAX: Mayor valor. • SUM: Suma de valores Ejemplo: En este ejemplo se obtienen todos los departamentos, la cantidad de empleados de cada departamento, el sueldo máximo y el sueldo promedio teniendo en consideración sólo aquellos departamentos que tengan más de 5 empleados. QUERIES Existen dos formas para definir “queries” en JP-QL: • La primera forma es definirlo dinámicamente en tiempo de ejecución como una cadena de caracteres que se construye de acuerdo al flujo de la aplicación. Esto implica compilar el “query” cada vez. • La segunda forma es definir el “query” vía anotación o XML y referenciarlo por el nombre cada vez que se requiera (algo similar a IBATIS). A diferencia de la forma anterior, los “queries nombrados” son estáticos, pero son mucho más eficientes para ser ejecutados. 4.2 CONSULTAS DINÁMICAS Un query se puede definir de forma dinámica simplemente pasando una cadena de caracteres con la sentencia JPQL al método createQuery() del EntityManager. Ahora bien, se puede indicar el resultado esperado o se puede omitir y de esta forma tendremos un query sin tipo definido ( “unTyped query” ).
  • 96. 96 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Para aquellas aplicaciones que utilizan muchos queries, se debe considerar el costo de “compilar” la sentencia JPQL: 1) Se ejecuta un “parse” de la cadena JPQL en un árbol de sintaxis para verificar que esté correctamente escrito. 2) Para cada entidad dentro de la expresión se obtiene la metadata. 3) Se genera la sentencia SQL equivalente. Se debe tener en consideración (al igual que en JDBC) las implicancias de concatenar un query y luego pasarlo al EntityManager para evitar la inyección de código SQL malicioso. Por ello es preferible usar parámetros. También, para aquellos queries empleados con mayor frecuencia, es preferible usar los queries nombrados ( NamedQueries ). Un ejemplo con TypeQuery: La sentencia JP-QL TypedQuery Clase que retorna el query La clase Order.java tiene un método toString()
  • 97. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 97 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES Un ejemplo con Query : 4.3 CONSULTAS NOMBRADAS Este tipo de query sirve para organizar y mejorar el desempeño de una aplicación. Se define empleado la anotación @NamedQuery, la cual se coloca dentro de la definición de una Entidad: la anotación define no solamente el nombre del query sino también la sentencia JPQL en sí. Se recomienda escribir los queries de manera ordenada de tal forma que ayuden a la visibilidad y lectura de los mismos dentro de la definición de la entidad. El nombre del query (atributo “name” ) debe ser único dentro de toda la unidad de persistencia. Si se hace caso omiso a esta restricción, los resultados pueden ser imprevisibles en tiempo de ejecución. Se puede definir múltiples queries nombrados empleando la anotación @NamedQueries, la cual es un arreglo que acepta varias anotaciones @NamedQuery. Ejemplo: El mismo query del ejemplo anterior, pero ahora definido en la clase Order.java La clase Order.java tiene un método toString() La sentencia JP-QL Query Query JPQL Nombre del Query
  • 98. 98 CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES CIBERTECCIBERTECCIBERTECCIBERTEC Se invoca así: Si deseamos definir varios NamedQueries en la entidad, se tendría que hacer así: Y se puede invocar así: Se especifica el nombre del Query Se especifica que es “NamedQuery” Query JPQL #1 Query JPQL #2 Anotación
  • 99. DE S AR RO L L O DE A P LI CA CI ON ES WE B II 99 CIBERTECCIBERTECCIBERTECCIBERTEC CARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALESCARRERAS PROFESIONALES 4.4 USO DE PARÁMETROS Los parámetros enviados a un “query” permiten la reutilización de sentencias de forma tal que las consultas ejecutadas con diferentes parámetros en cada invocación, retornen diferentes resultados. Es preferible enviar parámetros a las consultas en lugar de estar construyendo una nueva cadena de caracteres por cada invocación, pues así se evita compilar repetidas veces los “queries”. PARÁMETROS NOMBRADOS Se utilizan cuando dentro de la sentencia JPQL, los parámetros van precedidos por el símbolo de “:” seguido del nombre del parámetro. Al momento de ejecutar el query, el programador debe especificar el nombre del parámetro (empleando el método setParameter ) y el valor a ser cargado para reemplazarlo dentro de la sentencia JPQL. Los parámetros nombrados proporcionan claridad al código de la sentencia JPQL (cuando se utilizan nombres adecuados), por lo que son preferidos respecto a los parámetros ordinales. Ejemplo usando parámetros nombrados: Se especifica el nombre del Query