Model View Controller Architecture. Dra. Marcela Capobianco

Transcripción

1 Diseño y Desarrollo de Software Model View Controller Architecture Dra. Marcela Capobianco 1

2 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

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

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

5 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

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

7 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

8 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

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

10 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

11 Relación con patrones de diseño MVC separa el modelo de las vistas Un mismo modelo puede tener varias vistas asociadas

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

13 Patrón Observer

14 Patrón Observer Estructura de colaboración

15 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

16 Recordemoa: patrón Composite Intención: Compone objetos en estructuras de árbol para representar jerarquías de relación es-partede. 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.

17 Patrón Composite

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

19 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

20 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

21 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

22 Patrón Strategy - Estructura

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

24 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

25 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

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

27 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

28 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

29 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:

30 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

31 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 serverside application behavior.

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

33 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

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