150 likes | 307 Views
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).
E N D
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
Vista Modelo Output Controlador Input ArquitecturaMVC
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.
Servlet o Action Object Manager Gestión de Sesión y Contexto Centralización de la lógica de recuperación de Información Servlet o Action Servlet o Action Servlet o Action Servlet o Action Helper a Negocio
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