1 / 47

Modelo-Vista-Controlador (MVC)

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.

jacob
Télécharger la présentation

Modelo-Vista-Controlador (MVC)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

  5. Modelo-Vista-Controlador En general

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

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

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

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

  10. Modelo-Vista-Controlador

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

  12. Modelo-Vista-Controlador Clase Interfaz <<Interface>>: Recepcionar peticiones al sistema. Mostrar respuestas del sistema. • 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 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.

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

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

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

  16. 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); }

  17. PROXY

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

  19. 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”

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

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

  22. Proxy

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

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

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

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

  27. Proxy • Estructura

  28. Proxy • Diagrama de Secuencia

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

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

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

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

  33. PROXY/BROKER

  34. Proxy/Broker • Propósito 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.

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

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

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

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

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

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

  41. Proxy/Broker

  42. Proxy/Broker Diagrama de Secuencia

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

  44. Proxy/Broker

  45. Proxy/Broker

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

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

More Related