Embed Size (px)
DESCRIPTION
Capa de Presentación. 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. Patrón MVC (Model View Controller). - PowerPoint PPT Presentation
Citation preview
Capa dePresentación
Capa de PresentaciónResponsabilidades
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
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.
Patrón MVCHistoria
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
ArquitecturaMVC
Controlador
Vista
Modelo
Output
Input
MVCEl 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).
MVCLa 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.
MVCEl 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)
Persistencia de Entidadesen 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…
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
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.
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
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.
Centralización de la lógica de recuperación de Información
Servlet o
Action
Servlet o
Action
Servlet o
Action
Servlet o
Action
Servlet o
Action
Helper a Negocio
Object ManagerGestión de Sesión y Contexto
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
