Daniel Fernández Lanvin 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 Controlador Vista Modelo Output Input

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 Action Helper a Negocio Object Manager Gestión de Sesión y Contexto

Daniel Fernández Lanvin Referencias URLs Libros Programming Jakarta Struts de O’Reilly Mastering Tomcat Development de WILEY Java Server Programming J2EE Edition de Wrox