Capa de

Presentación

Daniel Fernández Lanvin

 Capa de Presentación
Responsabilidades

 Navegabilidad del sistema

 Formateo de los datos de salida
 Internacionalización
 Validación de los datos de entrada
 Interfaz gráfica de usuario
 Multicanalidad del sistema

Daniel Fernández Lanvin

 Patrón MVC
(Model View Controller)
 Patrón arquitectónico aportado por SmallTalk
 Modelo 2 de aplicaciones WEB
 Reparte las responsabilidades de la aplicación
entre tres elementos:
 El Modelo: Core de la aplicación. Reglas de negocio y
capa de persistencia
 La Vista: Renderizado del sistema
 El Controlador: Control del flujo de navegación de la
aplicación.

Daniel Fernández Lanvin

 Patrón MVC
Historia
 Inventado por Trygve Reenskaug
 Introducido en el entorno de desarrollo del
SmallTalk 80 desarrollador en XEROX PARC.
 Los elementos del MVC aparecen el varios
modelos de GUIs modernos
 MFCs
 Swing
 JSF
 Etc

Daniel Fernández Lanvin

 Arquitectura
MVC

Output Vista

Modelo

Input Controlador

Daniel Fernández Lanvin

 MVC
El modelo
 Encapsula los datos y reglas específicos de la
aplicación (Capa de negocio + Capa persistencia).
 Aporta:
 Métodos para el manejo de datos y servicios
 Métodos para acceder al estado del sistema.
 Mantiene registro de las diferentes vistas y
cotroladores para notificar los cambios (Modelo
de eventos).

Daniel Fernández Lanvin

 MVC
La Vista
 Mecanismo necesario para mapear los datos
provenientes del modelo al renderizado de la
interfaz.
 Cuando el Modelo cambia, la vista es informada.
 La vista solicita al modelo la información
 Se responsabiliza de actualizar la pantalla
 Detectar áreas defectuosas (quedan descubiertas cuando
estuvieron ocultas por otra ventana, por ejemplo).
 Redibujar la pantalla cuando se solicite.

Daniel Fernández Lanvin

 MVC
El controlador
 Intercepta los eventos de entrada
provenientes del usuario del sistema
 Traduce los eventos en invocaciones al
modelo de la aplicación
 Activa o desactiva los elementos de la
interfaz de usuario (en el ámbito de las
aplicaciones Windows, pone los botones
habilitados o en gris)

Daniel Fernández Lanvin

 Persistencia de Entidades
en Sesión
 El único medio para almacenar el estado de la
sesión del usuario en el servidor junto a la base de
datos.
 Nos sirve de caché
 Muy delicado. No se debe sobrecargar, dado que
existe una sesión por cada usuario activo.
 Origen potencial de problemas:
 La interfaz de la sesión es muy débilmente tipada, puesto
que almacenamos instancias de Object
 Solución: Centralizar la gestión de la sesión en un solo
punto…

Daniel Fernández Lanvin

 Persistencia de entidades
en Sesión – Gestor de Sesión y
Contexto
 Centralizamos TODA la lógica de manejo del objeto sesión y
del contexto en un solo objeto
 Hacemos que el objeto presente una interfaz rígida para
evitar los errores de programación …
 En tiempo de compilación, desarrollando un método para cada
objeto susceptible de ser cacheado
 Más robusto
 Más tedioso de desarrollar
 Difícil y costoso de mantener
 En tiempo de ejecución, comprobándolo en tiempo real y
contrastándolo con la configuración externalizada en XML
 Sólo se detectan los errores en tiempo de ejecución, pero se
detectan a la primera
 Componente reutilizable
 Fácil de mantener

Daniel Fernández Lanvin

 Persistencia de entidades
en Sesión – Gestor de Sesión y
Contexto
 En la sesión almacenamos y cacheamos los datos
propios del usuario. Ej.:
 UsuarioBean con las propiedades del usuario
 Lista de privilegios de acceso consultados a base de
datos.
 Etc.
 En el contexto podemos almacenar datos
comunes a distintos usuarios. Ej.:
 La lista de países que carga el combo box de la pantalla
de alta
 La lista de idiomas
 Etc.

Daniel Fernández Lanvin

 Persistencia de entidades
en Sesión – Consideraciones

 La sesión es delicada. Hay que tener en cuenta

que hay una por usuario activo, y que en una
aplicación web podemos tener de repente 500
usuarios simultáneos. Ojo con el tamaño de la
sesión!
 La sesión permanece activa durante un tiempo
determinado por lo que la presencia de usuarios
sobrecarga el sistema incluso si no es simultánea.
 El contexto es menos delicado, puesto lo que
metemos en el contexto se mete una sola vez para
todos.
 Hay que controlar la caducidad de la información
en el contexto
Daniel Fernández Lanvin
 Centralización de la lógica de
recuperación de Información
 Lógica de recuperación descentralizada: Cada vez
que necesitamos algo de negocio invocamos a la
capa directamente
 Problemas: Si cambia el origen del dato
tendremos que “tocar” todos los métodos que
invocan el método.
 Ej.: Cierto resultado de un método pasa a ser
cacheado en sesión o aplicación:
 el cierre mensual de facturación
 proceso muy pesado
 no cambia el resultado en todo el mes -> cacheado en
contexto con caducidad de 30 días.

Daniel Fernández Lanvin

 Centralización de la lógica de
recuperación de Información

Servlet o Servlet o Servlet o Servlet o Servlet o

Action Action Action Action Action

Object Manager
Gestión de
Sesión y
Contexto
Helper a Negocio

Daniel Fernández Lanvin

 Referencias
 URLs
 http://jakarta.apache.org/Struts
 http://theserverside.com
 Libros
 Programming Jakarta Struts de O’Reilly
 Mastering Tomcat Development de WILEY
 Java Server Programming J2EE Edition de Wrox

Daniel Fernández Lanvin