Apache Struts

1
Capa dePresentación
2
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

3
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.

4
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

5
ArquitecturaMVC
6
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).

7
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.

8
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)

9
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

10
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

11
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.

12
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

13
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 -gt cacheado
  en contexto con caducidad de 30 días.

14
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
15
Referencias

• URLs
• http//jakarta.apache.org/Struts
• http//theserverside.com
• Libros
• Programming Jakarta Struts de OReilly
• Mastering Tomcat Development de WILEY
• Java Server Programming J2EE Edition de Wrox