MODELO VISTA CONTROLADOR

INTRODUCCIÓN
El mercado del software de computadoras personales ha germinado en las pasadas dos
décadas. El procesamiento de texto, la hoja de cálculo, los gráficos por computadoras,
multimedia, entretenimientos, gestión de bases de datos, aplicaciones financieras, de
negocios y personales y redes o acceso a bases de datos externas son algunas de los
cientos de aplicaciones existentes en la actualidad.
En el mismo período de tiempo mencionado, han aparecido un conjunto de variantes de
solución al diseño y a la arquitectura de las aplicaciones de todo tipo. No obstante la
aplicación de dichas variantes a los software educativos se vuelve un poco compleja y en
ocasiones no compatibles con las características de este tipo de aplicacione.
http://www.monografias.com/trabajos43/patron-modelo-vista/patron-modelo-vista2.shtml

ORIGEN
EL Modelo Vista Controlador fue descrito por primera vez en 1979 por Trygve
Reenskaug, trabajador de Smalltalk en laboratorios de investigación de Xerox.
2.1. El modelo

El modelo es un conjunto de clases que representan la informacion del mundo

real
que el sistema debe procesar, así por ejemplo un sistema de administracion de
datos climatol
ogicos tendra un modelo que representara la temperatura, la humedad
ambiental,
el estado del tiempo esperado, etc. sin tomar en cuenta ni la forma en la que
esa informacion
va a ser mostrada ni los mecanismos que hacen que esos datos esten dentro
del
modelo, es decir, sin tener relacion con ninguna otra entidad dentro de la
aplicacion.

2.1.1. Modelo del dominio

Se podria decir que el modelo del dominio (o el modelo propiamente dicho) es

el
conjunto de clases que un ingeniero de software modela al analizar el problema
que desea
resolver; así, pertenecer´ýan al modelo del dominio: El cliente, la factura, la
temperatura,
la hora, etc. El modelo del dominio no deberia tener relacion con nada externo
a la
informacion que contiene.

2.1.2. Modelo de la aplicacion

El modelo de la aplicacion es un conjunto de clases que se relacionan con el
modelo
del dominio, que tienen conocimiento de las vistas y que implementan los
mecanismos
necesarios para notificar a ´estas ´ultimas sobre los cambios que se pudieren
dar en el
modelo del dominio. El modelo de la aplicacion es llamado tambien coordinador
de la
aplicacion

2.2. Las vistas

Las vistas son el conjunto de clases que se encargan de mostrar al usuario la

informacion
contenida en el modelo. Una vista esta asociada a un modelo, pudiendo existir
varias vistas asociadas al mismo modelo; asi por ejemplo, se puede tener una
vista mostrando
la hora del sistema como un reloj analogico y otra vista mostrando la misma
informacion como un reloj digital.
Una vista obtiene del modelo solamente la informaci´on que necesita para
desplegar
y se actualiza cada vez que el modelo del dominio cambia por medio de
notificaciones
generadas por el modelo de la

2.3. El controlador

El controlador es un objeto que se encarga de dirigir el flujo del control de la

aplicación debido a mensajes externos, como datos introducidos por el usuario
u opciones
del menu seleccionadas por ´el. A partir de estos mensajes, el controlador se
encarga de
modificar el modelo o de abrir y cerrar vistas. El controlador tiene acceso al
modelo y
a las vistas, pero las vistas y el modelo no conocen de la existencia del
controlador.
2.5. Ventajas

Desarrollar una aplicaci´on siguiendo este patron de diseño tiene muchas

ventajas:
La aplicaci´on esta implementada modularmente.
Sus vistas muestran informaci´on actualizada siempre.
El programador no debe preocuparse de solicitar que las vistas se actualicen,
ya
que este proceso es realizado automaticamente por el modelo de la aplicaci
´on.
Si se desea hacer una modificacion al modelo del dominio, como aumentar
metodos
o datos contenidos, solo debe modificarse el modelo y las interfaces del mismo
con
las vistas, no todo el mecanismo de comunicacion y de actualizacion entre
modelos.
Las modificaciones a las vistas no afectan en absoluto a los otros modulos de la
aplicaci´on.
MVC es bastante utilizado en la actualidad en marcos de aplicaci´on orientados
a objeto desarrollados para construir aplicaciones de gran tamaño; Java Swing,
Apache Struts, Microsoft ASP.NET, las transformaciones XSL o incluso los
documentos
LATEX siguen este patron de diseño.
MVC esta demostrando ser un patron de diseño bien elaborado pues las
aplicaciones
que lo implementan presentan una extensibilidad y una mantenibilidad ´unicas
comparadas con otras aplicaciones basadas en otros patrones.
2.6. Desventajas

El tiempo de desarrollo de una aplicaci´on que implementa el patron de diseño

MVC es mayor, al menos en la primera etapa, que el tiempo de desarrollo de
una aplicaci´on que no lo implementa, ya que MVC requiere que el
programador
implemente una mayor cantidad de clases que en un entorno de desarrollo
comun
no son necesarias. Sin embargo, esta desventaja es muy relativa ya que
posteriormente,
en la etapa de mantenimiento de la aplicaci´on, una aplicaci´on MVC es
muchisimo mas mantenible, extensible y modificable que una aplicaci´on que
no lo
implementa.
MVC requiere la existencia de una arquitectura inicial sobre la que se deben
construir
clases e interfaces para modificar y comunicar los modulos de una aplicaci´on.
Esta arquitectura inicial debe incluir, por lo menos: un mecanismo de eventos
para
poder proporcionar las notificaciones que genera el modelo de aplicaci´on; una
clase
Modelo, otra clase Vista y una clase Controlador genericas que realicen todas
las
tareas de comunicacion, notificacion y actualizacion que seran luego
transparentes
para el desarrollo de la aplicaci´on.
MVC es un patron de diseño orientado a objetos por lo que su implementacion
es
sumamente costosa y dificil en lenguajes que no siguen este paradigma.
498 · Ernesto Bascon: El patron de diseño Modelo-Vista-Controlador (MVC)

aplicaci
´on(http://www.ucbcba.edu.bo/Publicaciones/revistas/actanova/documentos/v2
n4/v2.n4.bascon.pdf)
DONDE ES UTILIZADO
Para el diseño de aplicaciones con sofisticados interfaces se utiliza el patrón de diseño
Modelo-Vista-Controlador. La lógica de un interfaz de usuario cambia con más frecuencia
que los almacenes de datos y la lógica de negocio. Si realizamos un diseño ofuscado, es
decir, un pastiche que mezcle los componentes de interfaz y de negocio, entonces la
consecuencia será que, cuando necesitemos cambiar el interfaz, tendremos que modificar
trabajosamente los componentes de negocio. Mayor trabajo y más riesgo de error.
Se trata de realizar un diseño que desacople la vista del modelo, con la finalidad de
mejorar la reusabilidad. De esta forma las modificaciones en las vistas impactan en menor
medida en la lógica de negocio o de datos.
Elementos del patrón:
• Modelo: datos y reglas de negocio
• Vista: muestra la información del modelo al usuario
• Controlador: gestiona las entradas del usuario

Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un
ejemplo clásico es el de la información de una base de datos, que se puede presentar de
diversas formas: diagrama de tarta, de barras, tabular, etc. Veamos cada componente:
El modelo es el responsable de:
○ Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo
sea independiente del sistema de almacenamiento.
○ Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de
regla puede ser: "Si la mercancía pedida no está en el almacén, consultar
el tiempo de entrega estándar del proveedor".
○ Lleva un registro de las vistas y controladores del sistema.
○ Si estamos ante un modelo activo, notificará a las vistas los cambios que
en los datos pueda producir un agente externo (por ejemplo, un fichero
bath que actualiza los datos, un temporizador que desencadena una
inserción, etc).
El controlador es responsable de:
○ Recibe los eventos de entrada (un clic, un cambio en un campo de texto,
etc.).
○ Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces
Acción W". Estas acciones pueden suponer peticiones al modelo o a las
vistas. Una de estas peticiones a las vistas puede ser una llamada al
método "Actualizar()". Una petición al modelo puede ser
"Obtener_tiempo_de_entrega( nueva_orden_de_venta )".
Las vistas son responsables de:
○ Recibir datos del modelo y los muestra al usuario.
○ Tienen un registro de su controlador asociado (normalmente porque
además lo instancia).
○ Pueden dar el servicio de "Actualización()", para que sea invocado por el
controlador o por el modelo (cuando es un modelo activo que informa de
los cambios en los datos producidos por otros agentes).
Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los datos) es
la navegación web, que responde a las entradas del usuario, pero no detecta los cambios
en datos del servidor.
El diagrama de secuencia:

Pasos:
1. El usuario introduce el evento.
2. El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque
también puede llamar directamente a la vista).
3. El modelo (si es necesario) llama a la vista para su actualización.
4. Para cumplir con la actualización la Vista puede solicitar datos al Modelo.
5. El Controlador recibe el control.
http://www.proactiva-calidad.com/java/patrones/mvc.html

El patrón de diseño de software Modelo – Vista – Controlador (MVC).

La arquitectura del software alude a "la estructura global del software y a las formas en
que la estructura proporciona la integridad conceptual de un sistema". En su forma más
simple, la arquitectura es la estructura jerárquica de los componentes del programa
(módulos), la manera en que los componentes interactúan y la estructura de datos que
van a utilizar los componentes. Sin embargo, en un sentido más amplio, los
"componentes" se pueden generalizar para presentar los elementos principales del
sistema y sus interacciones. [PRE01]
"El diseño arquitectónico define la relación entre los elementos estructurales principales
del software, los patrones de diseño que se pueden utilizar para lograr los requisitos que
se han definido para el sistema, y las restricciones que afectan a la manera en que se
pueden aplicar los patrones de diseño arquitectónicos" [SHA96].
Los patrones expresan el esquema fundamental de organización para sistemas de
software. Proveen un conjunto de subsistemas predefinidos; especifican sus
responsabilidades e incluyen reglas y guías para organizar las relaciones entre ellos; así
como ayudan a especificar la estructura fundamental de una aplicación.
MVC divide una aplicación interactiva en 3 áreas: procesamiento, salida y entrada. Para
esto, utiliza las siguientes abstracciones:
• Modelo (Model): Encapsula los datos y las funcionalidades. El modelo es
independiente de cualquier representación de salida y/o comportamiento de entrada.
• Vista (View): Muestra la información al usuario. Pueden existir múltiples vistas del
modelo. Cada vista tiene asociado un componente controlador.
• Controlador (Controller): Reciben las entradas, usualmente como eventos que
codifican los movimientos o pulsación de botones del ratón, pulsaciones de teclas, etc.
Los eventos son traducidos a solicitudes de servicio ("service requests") para el
modelo o la vista.
Se han desarrollado a lo largo de los años, desde la presentación de este patrón a la
comunidad científica 3 variantes fundamentales, que se presentan brevemente a
continuación.
Variante I:

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

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 III:
Variante en la cual se diversifica las funcionalidades del Modelo teniendo en cuanta las
características de las aplicaciones multimedia, donde tienen un gran peso las medias
utilizadas en estas.

IMPLEMENTACION DEL MVC

Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el
control generalmente es el siguiente:
1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el
usuario pulsa un botón, enlace)
2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la
acción solicitada por el usuario. El controlador gestiona el evento que llega,
frecuentemente a través de un gestor de eventos (handler) o callback.
3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de
forma adecuada a la acción solicitada por el usuario. 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 (si se utiliza la variante 2
descrita anteriormente, de lo contrario lo obtiene a través del Controlador). El modelo
no debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de
observador puede ser utilizado para proveer cierta indirección entre el modelo y la
vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un
objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el
modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos
 de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se
actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al
modelo, dejando que el controlador envíe los datos del modelo a la vista, según lo
descrito en la segunda variante.
5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo
nuevamente.
BENEFICIOS
• Menor acoplamiento.
a. Desacopla las vistas de los modelos.
b. Desacopla los modelos de la forma en que se muestran e ingresan los datos.
• Mayor cohesión.
a. Cada elemento del patrón esta altamente especializado en su tarea (la vista en
mostrar datos al usuario, el controlador en las entradas y el modelo en su objetivo
de negocio).
• Las vistas proveen mayor flexibilidad y agilidad.
a. Se puede crear múltiples vistas de un modelo.
b. Las vistas pueden anidarse.
c. Se puede cambiar el modo en que una vista responde al usuario sin cambiar su
representación visual.
d. Se puede sincronizar las vistas.
e. Las vistas pueden concentrarse en diferentes aspectos del modelo.
• Mayor facilidad para el desarrollo de clientes ricos en múltiples dispositivos y canales
a. Una vista para cada dispositivo que puede variar según sus capacidades.
b. Una vista para la Web y otra para aplicaciones de escritorio.
• Más claridad de diseño.
• Facilita el mantenimiento.
• Mayor escalabilidad.
http://www.monografias.com/trabajos43/patron-modelo-vista/patron-modelo-vista2.shtml