MVC. Modelo Vista - Controlador

Transcripción

1 MVC Modelo Vista - Controlador

2 Agenda Definiciones Contexto Colaboración entre clases Estrategias de control Enfoques MVC Push/Pull Modelo Activo/Pasivo Ejemplo Bibliografía

4 Definición de Patrón Un patrón es una solución probada que se puede aplicar con éxito a un determinado tipo de problemas que aparece con frecuencia. Esqueleto de aplicación básica que el diseñador ha de adaptar a sus necesidades. Un patrón de diseño en software es una colección de objetos que incluye: Relaciones entre estos objetos Desarrollados para resolver un problema concreto Se ha comprobado que funcionan bien (han sido testados).

5 Catálogo POSA Del fango a la estructura Sistemas distribuidos Sistemas interactivos Sistemas adaptables Capas Tubería-filtros Pizarra Broker (p. ej. CORBA, DCOM, Web Services, WWW) Model-View-Controller Presentation-Abstraction-Control Reflection: metanivel que hace al software consciente de sí mismo. Microkernel: núcleo de funcionalidad mínima. POSA: Pattern-Oriented Software Architecture

6 Definición de MVC Modelo Vista Controlador (MVC) es un patrón de diseño de software que separa el acceso a datos, la lógica de presentación y el control de flujo de una aplicación, en tres componentes distintos de forma que las modificaciones en alguno de los componentes puedan ser hechas con un mínimo impacto en los demás componentes. CLIENTE FRONT-END VISTA MODELO MIDDLEWARE CONTROLADOR BACK-END SGBD

7 Modelo-Vista-Controlador MVC es un patrón de diseño orientado a objetos. Fue desarrollado en el Centro de Investigaciones Xerox Palo Alto a finales de los años setenta. Define una buena arquitectura para un sitio web Especifica el uso de clases para dividir nuestra aplicación: Lógica del negocio * -> datos persistentes Lógica de presentación -> como visualizamos los datos Flujo de la aplicación -> a través del controlador * Algunas bibliografías llaman lógica de negocio a la capa media, que para el caso de MVC es la capa de control.

8 MVC: Modelo Modelo Vista Controlador Conjunto de Clases y Objetos correspondientes al Modelo del Negocio para nuestra aplicación (estados y funcionalidad) Es deseable un bajo acoplamiento con Vistas y Controladores Se definen métodos para realizar consultas (informar el estado), comandos (modificar el estado) y mecanismos de notificación (para informar a los observadores / vistas)

9 MVC: Vista Modelo Vista Controlador Administra la visualización y presentación de la información Observa al Modelo para actualizar los cambios Al definirse en el modelo una interfaz clara y estable, es fácil implementar múltiples Vistas para un mismo modelo Altamente dependiente del dispositivo y tecnología de visualización Muy dependiente del Modelo (debe conocerlo)

10 MVC: Controlador Modelo Vista Controlador Responsable de definir el comportamiento de la aplicación Recibe los eventos del usuario y decide qué es lo que se debe hacer, mapeándolos en comandos (mensajes) hacia el Modelo Altamente dependiente de los dispositivos y mecanismos de interacción del usuario Muy dependiente del Modelo (debe conocerlo)

11 Estructura de Clases: MVC Version 1

12 Estructura de Clases: MVC Version 2

14 Intención Desacoplar el acceso a datos y la lógica de negocio (Modelo) de la presentación de los datos y la interacción con el usuario (Vista). Para ello, MVC introduce un componente intermedio, el Controlador.

15 Contexto Aplicaciones interactivas con interfaces humanocomputador cambiantes y flexibles. Problema: Las interfaces de usuario son muy frecuentemente cambiadas. Cambios en la funcionalidad deben reflejarse en las interfaces. Puede haber interfaces a medida para ciertos usuarios. Diferentes paradigmas de interfaz: digitar información seleccionar íconos Construir un sistema monolítico es caro y difícil.

16 Motivación La misma información se presenta de distintas formas. Cambios en los datos deben reflejarse en la interfaz inmediatamente. Las interfaces deben modificarse fácilmente, ojalá durante la ejecución. Distintas interfaces portables no deben afectar la operación esencial.

17 Solución MVC divide la aplicación en procesamiento, input y output. El modelo representa la funcionalidad y los datos esenciales, y es independiente de la representación en las interfaces. La view obtiene datos del modelo y los despliega para el usuario. Cada view tiene asociada un controlador. El controlador recibe eventos como input (movimientos del mouse, activación de botones) y los traduce a solicitudes de servicios del modelo o la view. El usuario interactúa con el modelo solamente a través de controladores.

18 Consulta de Estado MVC Modelo Agrupa los estados de la aplicación Responde a los requerimientos Muestra la funcionalidad de la aplicación Notifica los cambios a la Vista Cambios de Estado Notificaciones de Cambios Vista Interpreta el modelo Solicita actualizaciones del modelo Envía las acciones del usuario al Controlador Permite al Controlador seleccionar las Vistas Invocación de Métodos Eventos Selección de Vista Acciones de Usuarios Controlador Define el comportamiento de la aplicación Mapea las acciones del Usuario a actualizaciones del Modelo Selecciona la Vista de respuesta Uno por cada funcionalidad

19 Arquitectura de Aplicaciones Web FRENTE FÍSICO Cliente/Servidor Especificación Arquitectónica Usuario FRENTE LÓGICO M-V-C Patrón Front-End Vista T I E R S Middleware Controlador L A Y E R S Back-End Modelo

21 Flujo Típico de Ejecución con MVC CLIENTE FRONT-END VISTA 6 1 MODELO 5 2 MIDDLEWARE CONTROLADOR 4 3 BACK-END SGBD

22 Funcionamiento Flujo de ver información: LADO DEL CLIENTE LADO DEL SERVIDOR Petición 1 Controlador Datos Persistentes Respuesta 8 7 Vista 3 6 Modelo

23 Funcionamiento Flujo de actualizar información: LADO DEL CLIENTE LADO DEL SERVIDOR Petición 1 Controlador Redirección 7 Modelo 3 4 Datos Persistentes Petición 8

24 Otros Esquemas: Funcionamiento Modelo 3 1 Controlador 2 4 SGBD 5 CLIENTE 6 Vista

25 Funcionamiento en J2EE response request Controller (Servlet) forward View (JSP) update get information Model (JavaBean)

27 Page Controller Este patrón: Intercepta la llamada a la página solicitada. Interpreta la acción. Ejecuta la acción. Determina la vista correcta para mostrarle los resultados al usuario. Separa la lógica de despacho de cualquiera de las vistas. Cuando se implementa de forma adecuada, crea una base común para todos los controladores para evitar la duplicación de código e incrementar la consistencia y facilidad de prueba. 27 Raúl Andrés de Villa Cano

28 Page Controller Estructura: Model Lógica de negocio PageController Manejar requerimientos HTTP Actualizar el modelo Decidir siguiente vista View Generar HTML 28

29 Page Controller Usando ControllerBase para eliminar duplicación de código: BaseController Comportamiento común Page1Controller Comportamiento específico de la Página 1 Page2Controller Comportamiento específico de la Página 2 29 Raúl Andrés de Villa Cano

30 Front Controller El patrón se relaciona con el diseño de aplicaciones web. Ofrece un punto de acceso centralizado para el tratamiento de todas las solicitudes. Este patrón: Canaliza todas las peticiones en un único controller. El controller se implementa en dos partes: un handler y una jerarquía de comandos. 30 Raúl Andrés de Villa Cano

31 Front Controller Estructura: Client Handler «interface» Command +Execute() : void Concrete Command 1 Concrete Command 2 31 Raúl Andrés de Villa Cano

32 Escenario típico: Front Controller client: :Handler :Command :View Send(Request) Execute(Request) Transfer(Request) 32 Raúl Andrés de Villa Cano

33 Controlador Frontal View Controller Model Browers JSP / HTML Form 1 Struts ActionServlet 3 Struts Action 2 struts-config.xml 6 Business Logic using Struts Custom Tags 4 5 Struts ActionForm Database 1. Todas las solicitudes del navegador son enviadas al Struts ActionServlet. 2. El Struts ActionServlet determina cual subclase Action enrutar usando el archivo de mapeo predeterminado struts-config.xml. 3. El ActionServlet pasa el control a la subclase Action. 4. Cuando el formulario HTML es enviado, la subclase ActionForm es automáticamente poblada con los datos del formulario. 5. La subclase Action puede acceder a los datos del formulario que están almacenados en la subclase ActionForm. Esta subclase es pasada al back-end del Business Logic para futuras acciones. 6. La subclase Action invoca el back-end del Business Logic.

35 Enfoques MVC Push/Pull Hace referencia a cómo son accesibles los objetos de la capa de negocio desde la capa de presentación. MVC Push es cuando los datos son seteados en la vista. En este escenario, generalmente un objeto de la capa de negocio está asociado a una página. MVC Pull es cuando la vista pide los datos (por ejemplo, mediante métodos accesores). En este escenario, generalmente uno o varios objetos están disponibles para todas las páginas. La mayoría de frameworks sigue un enfoque MVC Push.

36 Enfoques MVC Push/Pull ENFOQUE PUSH CLASE DE NEGOCIO public class{ varvista = 5; } PLANTILLA DE LA VISTA <div class="grid"> <com:tliteral ID= varvista" /> </div> ENFOQUE PULL OBJETO DE NEGOCIO n:negocio atributo1 = 3 atributo2 = Dato atributo3 = 50 CLASE DE LA VISTA public class{ varvista = getatributo3(); }

37 Enfoque MVC Push ENFOQUE PUSH CLASE DE NEGOCIO class { this.totaldatos= ; } PLANTILLA DE LA VISTA <div class="grid"> <com:tliteral ID= totaldatos" /> </div>

38 Enfoques MVC Push/Pull ENFOQUE PULL OBJETO DE NEGOCIO GestionarPersonasController cedula = nombre = Luis Carlos Velez Blanco = lcvb@hotmail.com CLASE DE LA VISTA class extends View{ varvista = getcedula() ; }

40 Modelo Pasivo El Model no reporta cambios de estado El controller es el único que manipula el modelo. Cuando el controller modifica el modelo le informa a la vista que este ha cambiado y que ya se puede refrescar. En este escenario el modelo es completamente independiente.

41 Modelo Pasivo Modelo update Vista Eventos Totalmente desacoplado Vistas escuchan y responden a los eventos de notificación de sus respectivos modelos (si les interesa) Modelo desconoce qué pasa, sólo responde a los mensajes recibidos (comandos y consultas)

42 Modelo Pasivo CONTROLADOR MODELO VISTA

43 Modelo Pasivo

44 Modelo Activo El Modelo reporta cambios de estado a vistas Este es usado cuando el modelo cambia su estado sin intervención del controller. Esto ocurre cuando otras fuentes cambian los datos y estos cambios debes ser reflejados en las vistas. Patrón Observer (Publish/Subscribe)

45 Modelo Activo Modelo update Observador Vista 4 Vista 3 Vista 2 Vista 1 Observadores / Vistas Asociadas Modelo conoce la existencia de observadores o vistas asociadas Les envía activamente un mensaje de notificación (sin información) Fácil de implementar, pero limitado en flexibilidad El controlador también puede observar al modelo

46 Modelo Activo CONTROLADOR MODELO <<interface>> Observer VISTA

47 Modelo Activo

48 Funcionamiento input Controlador register Vista Vista Vista update Modelo update

50 Ejemplo: Agenda de Proyectos Modelo de Dominio:

51 Ejemplo: Agenda de Proyectos Diagrama de Casos de Uso:

52 Ejemplo: Agenda de Proyectos Diagrama de Clases de Diseño:

53 Ejemplo: Agenda de Proyectos Implementación MVC genérico:

55 Bibliografía Buschmann, Frank et al.: Pattern Oriented Software Architecture, Volume 1: A System of Patterns, Willey & Sons, Gamma E., Helm, R., Johnson, R., Vlissides J.: Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley, Reenskaug, Trygve: Models-Views-Controllers, Xerox Research Center, Palo Alto, Burbeck, Steve: Applications Programming in Smalltalk-80: How to use Model-View-Controller(MVC), Bergin, Joseph: Building Graphical User Interfaces with the MVC Pattern. Pace Universiy,