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
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 proxyservidor 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

Descargar

Modelo-Vista-Controlador (MVC)