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.