1
Diseño y Desarrollo de Software
Model View Controller Architecture
Dra. Marcela Capobianco
¿Qué es MVC?
Model View Controller (MVC) es un patrón agregado que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos
El patrón MVC se ve frecuentemente en aplicaciones web
En este caso la vista es la página HTML y el código que provee de datos dinámicos a la página
Componentes
Modelo: representación específica del dominio de la información sobre la cual funciona la aplicación.
La lógica de dominio añade significado a los datos. Ejemplo: calcular los importes en un carrito de compras
Vista: presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario.
Componentes
Controlador: responde a eventos, usualmente acciones del usuario, e invoca cambios en el modelo y probablemente en la vista.
Muchas aplicaciones utilizan un mecanismo de almacenamiento (base de datos)
MVC no menciona específicamente esta capa de acceso a datos.
De donde surge
En general una aplicación tiene tres capas principales: presentación (UI), dominio, acceso a datos
MVC divide la capa de presentación en controlador y vista.
Existen muchas implementaciones diferentes de MVC que en general siguen el mismo flujo de control
Flujo de control
1.El usuario interactúa con la interfaz (por ejemplo, el usuario pulsa un botón)
2.El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción del usuario (gestor de eventos)
3.El controlador accede al modelo, modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario)
Flujo de control
Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario.
La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (ej: produce un listado del contenido del carro de la compra)
Flujo de control
El modelo no debe tener conocimiento directo sobre la vista.
El patrón de observador puede ser utilizado para proveer cierta indirección entre el modelo y la vista
Esto permite al modelo notificar a los interesados de cualquier cambio.
Un objeto vista puede registrarse con el modelo y esperar a los cambios, aun así el modelo en sí mismo sigue sin saber nada de la vista
Flujo de control
El controlador no pasa objetos de dominio (modelo) a la vista aunque puede dar la orden a la vista para que se actualice.
En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.
5. La interfaz espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
Flujo de control
El paradigma MVC crea al objeto controlador entre la vista y el modelo para ocmunicarse.
La implementación del controlador puede variar pero la idea es transformar eventos en cambios en los datos
Relación con patrones de diseño
MVC separa el modelo de las vistas
Un mismo modelo puede tener varias vistas asociadas
Recordemos: patrón Observer•Intención: Define una dependencia entre objetos de uno-a-muchos de forma tal que cuando un objeto cambia de estado, todos sus dependientes son notificados y actualizados acordemente.
•Alias: Dependents, Publish-Suscribe•Aplicabilidad: Usaremos este patrón cuando:
• Cuando una abstracción tiene dos aspectos, uno independiente del otro.• Cuando un cambio a un objeto requiere cambios en otros, y no sabemos cuántos objetos necesitan ser cambiados.• Cuando un objeto debería notificar a otros objetos sin realizar suposiciones de quiénes son esos objetos (evitar el acoplamiento)
Patrón Observer
Patrón Observer
•Estructura de colaboración
Relación con patrones de diseño
Para desconectar las vistas del modelo se utiliza el patrón observer
Las vistas en MVC pueden estar anidadas
Un panel de control puede contener botones tal que c/u es implementado como una vista
Se usa una subclase de view llamada compositeview
Queremos tratar a compositeview de la misma forma que se trata a sus componentes
Recordemoa: patrón Composite
•Intención: Compone objetos en estructuras de árbol para representar jerarquías de relación “es-parte-de”.
•Aplicabilidad: Usaremos este patrón cuando:• Queremos representar jerarquías de objetos modelando la relación “es-parte-de” (part-whole hierarchies)• Queremos que el cliente ignore la distinción entre objetos compuestos y objetos individuales. El cliente tratará todos los objetos de la estructura compuesta de manera uniforme.
Patrón Composite
Patrón Composite
• Component: declara la interfaz para los objetos en la composición.
• Implementa el comportamiento por defecto para todos los objetos.
• Declara la interfaz para acceder y manipular los componentes hijos.
• Opcionalmente implementa una interfaz para acceder al padre.
Patrón Composite
• Leaf: representa los objetos simples en la composición. Define el comportamiento de tipos primitivos.
• Composite: define el comportamiento para componentes compuestos. Almacena estos componentes e implementa operaciones relacionadas a su administración.
• Client: Manipula los objetos en la composición por medio de la interfaz Component.
Este patrón simplifica la implementación del cliente
Relación con patrones de diseño
Queremos tratar a compositeview de la misma forma que se trata a sus componentes
Para esto usamos el patrón composite
También permite cambiar la forma que una vista responde al usuario sin cambiar su representación visual
Basta con reemplazar la instancia del controlador
Patrón Strategy
•Intención: Define una familia de algoritmos, encapsula cada uno convirtiéndolos en intercambiables. Permite variar un algoritmo independientemente de los clientes que lo utilizan.
•Alias: Policy•Aplicabilidad: Usaremos este patrón cuando:
• Muchas clases relacionadas difieren únicamente en el comportamiento.• Necesitamos diferentes variantes de un algoritmo.• Un algoritmo utiliza datos que el cliente no debe conocer.• Una clase define múltiples comportamientos, y éstos figuran como sentencias condicionales múltiples en sus operaciones.
Patrón Strategy - Estructura
Patrón Strategy
•Participantes:• Strategy: declara una interfaz común a todos los
algoritmos soportados.• ConcreteStrategy: implementa un algoritmo
utilizando la interfaz Strategy.• Context: está configurado con un objeto de tipo
ConcreteStrategy. Mantiene una referencia a un objeto Strategy. Puede definir, si es necesario, una interfaz para que Strategy acceda a sus datos.
Relación con patrones de diseño
El patrón Strategy nos permitirá cambiar la instancia del controlador aún en tiempo de ejecución
Por ejemplo, una vista puede ser desabilitada simplemente creando una instancia de controller que ignora los eventos de entrada
Análisis
Siempre hay que considerar si es la opción más conveniente para la situación dada
Posee ventajas dado que la estabilidad del modelo no es la misma que la de la vista
Si el modelo fue construido correctamente es en general bastante estable
Esto no es cierto para la interfase
Separarlos hace que el modelo sea más robusto
Implementaciones
Fue descripto por primera en 1979 por Trygve Reenskaug
El autor trabajaba para Xerox research labs sobre Smalltalk
La implementación original se describe en: Applications Programming in Smalltalk-80(TM):How to use Model-View-Controller.
Implementaciones
Esta implementación inspiró a muchos otros como:
• Cocoa y GNUstep, usan MVC.
• Microsoft Foundation Classes (MFC).
• Java Swing GUI library.
• Qt Toolkit desde Qt4 Release.
Más recientemente se lo ha propuesto como solución para aplicaciones Web
Implementaciones
Implementaciones más populares orientadas a la web:
JavaServer Faces
Apache Struts
Webwork2
Apache Struts está orientado a las páginas enteras y JSF a un nivel de componentes
Java Server Faces
JavaServer Faces (JSF) es un application framework basado en Java
Simplifica el desarrollo de interfases para aplicaciones Java EE
JSF usa JavaServer Pages como display technology y puede acomodar otras tecnologías:
Java Server Faces
JSF incluye:
Un conjunto de APIs paa representar componentes de la interfaz de usuario, manejar su estado, eventos, entrada, accesibilidad, internacionalización
Conjunto default de UI
Dos librerias JavaServer Pages (JSP) para disponer de un interfase JSF en un página JSP.
Server-side event model
Objetivos de diseño
Crear un framework de componentes GUI estandard que pueda hacer más facil para los usuarios de los tools desarrollar GUIs y manejar las conexiones con el comportamiento
Definir un conjunto de clases básicas para GUI components, component state, y eventos de entrada.
Proveer un modelo JavaBeans para enviar eventos desde el client-side GUI al server-side application behavior.
Objetivos de diseño
Definir APIs para validación de la entrada, incluyendo soporte para client-side validation
Especificar un model para internationalición y localización de la GUI
Generación automatica de salida apropiada para el cliente (tomando en cuenta configuration data, browser version, etc).
Struts
Estuvo dentro del Jakarta Project y actualmente es un proyecto top level
Es un open-source framework para desarrollar Java EE aplicaciones web
Usa y extiende el API Java Servlet para fomentar el uso de la architectura MVC
Fue creado originalmente por Craig McClanahan y donado a la Apache Foundation en el 2000
Struts
Permite el diseño e implementación de grandes aplicaciones web por grandes grupos de desarrolladores
Diseñadores de páginas, componentes y otros desarrolladores pueden trabajar en forma desacoplada
Incorpora I18N (internationalization), form validation y variedad de presentation layers: JSP, XML/XSLT, JavaServer Faces (JSF)
También model layers:JavaBeans and EJB.