Modelo-Vista-Controlador (MVC) Edgardo Bermúdez Pedro Martínez Víctor González

Modelo-Vista-Controlador Este patrón fue descrito por primera vez por Trygve Reenskaug en 1979, y la implementación original fue realizada en Smalltalk en los laboratorios Xerox. MVC se basa en la separación de la aplicación en tres capas principales: Modelo, Vista y Controlador. Se usa (él o alguna de sus variantes) en la gran mayoría de las interfaces de usuario.

Modelo-Vista-Controlador Modelo: es la representación específica del dominio de la información sobre la cual funciona la aplicación. El modelo es otra forma de llamar a la capa de dominio. La lógica de dominio añade significado a los datos; por ejemplo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o portes en un carrito de la compra.

Modelo-Vista-Controlador Vista: Se presenta el modelo en un formato adecuado para interactuar, usualmente un elemento de interfaz de usuario. Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista.

Modelo-Vista-Controlador En general

Modelo-Vista-Controlador Muchas aplicaciones utilizan un mecanismo de almacenamiento persistente (como puede ser una base de datos) para almacenar los datos. MVC no menciona específicamente esta capa de acceso a datos porque supone que está encapsulada por el modelo. El objetivo primordial del MVC es la reutilización del código ya implementado. Esta tarea se facilita mucho si a la hora de programar tenemos la precaución de separar el código en varias partes que sean susceptibles de ser reutilizadas sin modificaciones.

Modelo-Vista-Controlador Ejemplos Los datos de una hoja de cálculo pueden mostrarse de en formato tabular, con un gráfico de barras, con uno de sectores. Los datos son el modelo. Si cambia el modelo, las vistas deberían actualizarse en consonancia. El usuario manipula el modelo a través de las vistas. 􀁺 (en realidad, a través de los controladores)

Modelo-Vista-Controlador Mas de una Vista de un Modelo de Datos

Modelo-Vista-Controlador MVC es utilizado con mayor frecuencia en las aplicaciones web, donde la Vista es la página HTML, y el Controlador es el código que reúne la data dinámica y genera el contenido de la página. El Modelo es representado por el contenido actual, que usualmente se encuentra almacenado en una base de datos o en archivos XML.

Modelo-Vista-Controlador

Modelo-Vista-Controlador Fortalezas 􀁻 Se presenta la misma información de distintas formas. 􀁻 Las vistas y comportamiento de una aplicación deben reflejar las manipulaciones de los datos de forma inmediata. 􀁻 Debería ser fácil cambiar la interfaz de usuario (incluso en tiempo de ejecución). 􀁻 Permitir diferentes estándares de interfaz de usuario o portarla a otros entornos no debería afectar al código de la aplicación.

Modelo-Vista-Controlador En UML Se propone para el desarrollo del Modelo de Análisis de las aplicaciones, tres tipos de clases fundamentales, con las cuales podemos expresar todas las funciones de cualquier software, con sus respectivas responsabilidades Clase Interfaz <<Interface>>: Recepcionar peticiones al sistema. Mostrar respuestas del sistema. Clase Entidad <<Entity>>: Gestionar datos (información) necesaria para el sistema. Almacenar datos (información) persistentes del sistema. Provee la funcionalidad principal de la aplicación Clase Controlador <<Controller>>: Procesar Información del sistema. Gestionar visualización de respuesta del sistema. Obtiene los datos del modelo.

Modelo-Vista-Controlador Variantes del Modelo. - Variante en la cual no existe ninguna comunicación entre el Modelo y la Vista y esta última recibe los datos a mostrar a través del Controlador. Variante inicial del Patrón MVC.

Modelo-Vista-Controlador Variante en la cual se desarrolla una comunicación entre el Modelo y la Vista, donde esta última al mostrar los datos los busca directamente en el Modelo, dada una indicación del Controlador, disminuyendo el conjunto de responsabilidades de este último. Variante Intermedia del Patrón MVC.

Modelo-Vista-Controlador Muchas interfaces gráficas de usuario, como Swing o MFC, hacen innecesario el uso de un controlador. 􀁺 Definen su propio flujo de control y manejan los eventos internamente. 􀁺 Integran, así, la vista y el controlador. 􀁺 A esta variante se la suele denominar Document-View

Modelo-Vista-Controlador Un controlador (controlador.java, por ejemplo) puede gestionar el clic en un botón, de tal forma que recoge datos por medio del Modelo (model.cargar_texto(..)) y los manda a la Vista (el applet) para su actualización (vista.mostrar_texto( )): /**************************************************************** Responde al click en botón "abrir" La respuesta al evento es hacer que se abra en la vista el archivo correspondiente a la referencia seleccionada en el combo box ****************************************************************/ void b_abrir_actionPerformed(ActionEvent e) { … String texto_archivo = model.cargar_texto( indice_ref ); // Obtener texto de archivo /*** Si la carga de archivo es ok, lo muestro. Si no, aviso de error ****/ if (texto_archivo != null) { vista.mostrar_texto(texto_archivo); // Mostrar texto vista.mostrar_aviso("Carga de " + path + " completada."); } else vista.mostrar_aviso("Error en la carga de " + path);

PROXY

Proxy Propósito Proporciona un sustituto de otro objeto con el fin de controlar su acceso. Motivación Razón para controlar el acceso a un objeto: Diferir el coste de su creación e inicialización hasta que el objeto realmente se necesite.

Proxy Ejemplo Editor de documentos que permite objetos gráficos, abrir un documento debería ser rápido realmente, no todos los objetos son visibles a la vez Solución Crear los objetos “bajo demanda”

Proxy Solución Usar un objeto que sustituya a la imagen real (PROXY). El proxy actúa como si fuese la imagen y la instancia cuando es necesario.

Proxy Solución La imagen está guardada en archivos separados y el Proxy guarda el nombre del archivo como la referencia al objeto real. El Proxy también guarda el tamaño.

Proxy

Proxy El editor de documento accede a la imagen a través de la interfaz definida por la clase abstracta Graphic ImageProxy es una clase para las imágenes que es creada por demanda, contiene el nombre del archivo como una referencia a la imagen en el disco El nombre del archivo es pasado como argumento al constructor de ImageProxy .

Proxy ImageProxy también guarda el tamaño de la imagen y una referencia a la instancia real. Esta referencia no será valida hasta que el Proxy instancie la imagen real. La operación Draw se asegura que la imagen esta instanciada antes de responder la solicitud. GetExtent reenvía la solicitud a la imagen solo si ya fue instanciada, de lo contrario ImageProxy devuelve el tamaño que tiene guardado.

Proxy Aplicaciones Donde exista la necesidad de referenciar un objeto de forma más versátil y sofisticada que un puntero. Proxy remoto (Ambassador / Embajador) Proporciona un representante local de un objeto en un espacio de memoria diferente. Proxy virtual Para crear objetos de gran tamaño bajo demanda.

Proxy Proxy de protección Controla el acceso al objeto original. Es útil si el objeto original tiene diferentes derechos de acceso. Referencia elegante (smart pointers) Realiza acciones adicionales cuando se acceden a los elementos referenciados

Proxy Estructura

Proxy Diagrama de Secuencia

Proxy Participantes Proxy Mantiene un referencia al objeto real Mantiene un mismo interfaz que el objeto real Mantiene el acceso al objeto real Codificación de peticiones, Caching de información, comprobar permisos

Proxy Participantes Subject Define el interfaz común a Proxy y RealSubject RealSubject Define el objeto real que representa el Proxy

Proxy Consecuencias El proxy introduce un nivel de indirección cuando accede a un objeto. La indirección tiene muchos usos dependiendo del tipo de proxy: Remoto: ocultar espacio de memoria. Virtual: optimizaciones, creando objetos bajo demanda Protección: tareas adicionales.

Proxy Relacionados Si ofrece un interfaz distinto (proxy de seguridad) Adapter Tiene una implementación similar a Decorator

PROXY/BROKER

Proxy/Broker Propósito Motivación Estructurar sistemas distribuidos en los cuales surge la necesidad de una iteración remota entre componentes. Motivación Desacoplar la interacción de los usuarios en los clientes y servidores.

Proxy/Broker Ejemplo En el desarrollo de un “Mercado Web” tenemos desarrollados dos agentes, el comprador y el vendedor. Pero estos están desarrollados en plataformas diferentes que no permite que tengan comunicación.

Proxy/Broker Solución Cuando un cliente necesita comprar un producto, solicita a través de un Proxy al agente Broker los vendedores que tiene registrado. El Broker se comunica por un Proxy con el servidor para llevar a cabo la petición.

Proxy/Broker Solución El agente Broker entrega la información necesaria a el proxy-cliente y al proxy-servidor para que estos establezcan una comunicación efectiva que permita realizar la operación.

Proxy/Broker Los broker permiten realizar conexiones entre clientes y servidores de diferentes plataformas. Le entregan la información necesaria a los Proxy para que estos realicen las conexiones.

Proxy/Broker Otro ejemplo El broker sirve de intermediario entre el comprador y el vendedor. Permitiendo que logren conectarse y realizar la transacción.

Proxy/Broker Los patrones Proxy/Broker se pueden implementar de diferentes maneras, esto depende de los requerimientos de los sistemas. Una Forma de implementarlos es permitiendo que los Proxy cliente y servidor se comuniquen entre ellos cuando es posible.

Proxy/Broker

Proxy/Broker Diagrama de Secuencia

Proxy/Broker Otra manera muy usada es no permitir que los Proxy cliente y servidor se comuniquen. Esta restricción podría ser necesaria por políticas de seguridad de los servidores. También por mantener un orden y control de todo lo que pasa por los Proxys.

Proxy/Broker

Proxy/Broker

Proxy/Broker Consecuencias Aislamiento: Entre la aplicación y los servidores. Sencillez: permite que sea mas sencilla la construcción de los sistemas. Flexibilidad: Permite cambiar capas sin afectar las aplicaciones relacionadas con esta.

Proxy/Broker Ejemplos Este patrón es muy usado por sistemas con estándar CORBA (Arquitectura común de intermediarios en peticiones a objetos). Microsofts OLE 2.x World Wide Web ATM-P