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 realque el sistema debe procesar, así por ejemplo un sistema de administracion de datos climatologicos 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 informacionva a ser mostrada ni los mecanismos que hacen que esos datos esten dentro delmodelo, 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 elconjunto de clases que un ingeniero de software modela al analizar el problema que desearesolver; 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 lainformacion que contiene.

2.1.2. Modelo de la aplicacion

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

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 existirvarias vistas asociadas al mismo modelo; asi por ejemplo, se puede tener una vista mostrandola hora del sistema como un reloj analogico y otra vista mostrando la mismainformacion como un reloj digital.Una vista obtiene del modelo solamente la informaci´on que necesita para desplegary se actualiza cada vez que el modelo del dominio cambia por medio de notificacionesgeneradas 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 opcionesdel menu seleccionadas por ´el. A partir de estos mensajes, el controlador se encarga demodificar el modelo o de abrir y cerrar vistas. El controlador tiene acceso al modelo ya 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, yaque este proceso es realizado automaticamente por el modelo de la aplicaci´on.Si se desea hacer una modificacion al modelo del dominio, como aumentar metodoso datos contenidos, solo debe modificarse el modelo y las interfaces del mismo conlas 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 laaplicaci´on.MVC es bastante utilizado en la actualidad en marcos de aplicaci´on orientadosa objeto desarrollados para construir aplicaciones de gran tamaño; Java Swing,Apache Struts, Microsoft ASP.NET, las transformaciones XSL o incluso los documentosLATEX siguen este patron de diseño.MVC esta demostrando ser un patron de diseño bien elaborado pues las aplicacionesque lo implementan presentan una extensibilidad y una mantenibilidad ´unicascomparadas con otras aplicaciones basadas en otros patrones.

2.6. Desventajas

El tiempo de desarrollo de una aplicaci´on que implementa el patron de diseñoMVC es mayor, al menos en la primera etapa, que el tiempo de desarrollo deuna aplicaci´on que no lo implementa, ya que MVC requiere que el programadorimplemente una mayor cantidad de clases que en un entorno de desarrollo comunno 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 esmuchisimo mas mantenible, extensible y modificable que una aplicaci´on que no loimplementa.MVC requiere la existencia de una arquitectura inicial sobre la que se deben construirclases e interfaces para modificar y comunicar los modulos de una aplicaci´on.Esta arquitectura inicial debe incluir, por lo menos: un mecanismo de eventos parapoder proporcionar las notificaciones que genera el modelo de aplicaci´on; una claseModelo, otra clase Vista y una clase Controlador genericas que realicen todas lastareas de comunicacion, notificacion y actualizacion que seran luego transparentespara el desarrollo de la aplicaci´on.MVC es un patron de diseño orientado a objetos por lo que su implementacion essumamente 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/v2n4/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:

o Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.

o 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".

o Lleva un registro de las vistas y controladores del sistema. o 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:

o Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).

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

o Recibir datos del modelo y los muestra al usuario. o Tienen un registro de su controlador asociado (normalmente porque

además lo instancia).

o 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