El patrón de arquitectura MVC (Modelo Vista Controlador) es un patrón que define la organización independiente del Modelo (Objetos de Negocio), la Vista (interfaz con el usuario u otro sistema) y el Controlador (controlador del workflow de la aplicación).

El patrón de arquitectura "modelo vista controlador", es una filosofía de diseño de aplicaciones, compuesta por:

Ø Modelo

o Contiene el núcleo de la funcionalidad (dominio) de la aplicación.

o Encapsula el estado de la aplicación.

o No sabe nada / independiente del Controlador y la Vista.

Ø Vista

o Es la presentación del Modelo.

o Puede acceder al Modelo pero nunca cambiar su estado.

o Puede ser notificada cuando hay un cambio de estado en el Modelo.

Ø Controlador

o Reacciona a la petición del Cliente, ejecutando la acción adecuada y creando el modelo pertinente

Para entender cómo funciona nuestro patrón Modelo vista controlador, se debe entender la división a través del conjunto de estos tres elementos y como estos componentes se comunican unos con los otros y con otras vistas y controladores externos a el modelo principal. Para ello, es importante saber que el controlador interpreta las entradas del usuario (tanto teclado como el ratón), enviado el mensaje de acción al modelo y a la vista para que se proceda con los cambios que se consideren adecuados

Comunicación

El modelo, la vista y el controlador deben comunicarse de una manera estable los unos con los otros, de manera que sea coherente con las iteraciones que el usuario realizara. Como es lógico la comunicación entre la vista y el controlador es bastante básica pues están diseñados para operar juntos, pero los modelos se comunican de una manera diferente, un poco más sutil

Utilizado en múltiples frameworks

Ø Java Swing

Ø Java Enterprise Edition (J2EE)

Ø XForms (Formato XML estándar del W3C para la especificación de un modelo de proceso de datos XML e interfaces de usuario

Ø Como formularios web)

Ø GTK+ (escrito en C, toolkit creado por Gnome para construir

Ø aplicaciones gráficas, inicialmente para el sistema X Window)

Ø ASP.NET MVC Framework (Microsoft)

Ø Google Web Toolkit (GWT, para crear aplicaciones Ajax con Java)

Ø Apache Struts (framework para aplicaciones web J2EE)

Ø Ruby on Rails (framework para aplicaciones web con Ruby)

Ø Etc., etc., etc.

Modelo pasivo

No es necesario para el modelo hacer ninguna tener alguna disposición a él, simplemente basta con tener en cuenta su existencia. El modelo no tiene ninguna responsabilidad para comunicar los cambios a la vista porque ocurren solo por orden del usuario, por lo que esta función la llevara a cabo el controlador porque será el que interprete las ordenes de este usuario debido a que solo debe comunicar que algo ha cambiado. Por esto, el modelo es se encuentra en modo inconsciente y su participación en este caso es irrisoria.

Unión del modelo con la vista y el controlador

Como no todos los modelos pueden ser pasivos, necesitamos algo que comunique al controlador y a la vista, por lo que en este caso, sí que necesitamos el modelo, ya que solo este puede llevar a cabo los cambios necesarios al estado actual en el que estos se encuentran.

Al contrario que el modelo, que puede ser asociado a múltiples asociaciones con otras vistas y controladores, cada vista solo puede ser asociada a un único controlador, por lo que han de tener una variable de tipo controler que notificara a la vista cuál es su controlador o modelo asignado. De igual manera, el controlador tiene una variable llamada View que apunta a la vista. De esta manera, pueden enviarse mensajes directos el uno al otro y al mismo tiempo, a su modelo.

Al final, la vista es quien lleva la responsabilidad de establecer la comunicación entre los elementos de nuestro patrón MVC. Cuando la vista recibe un mensaje que concierne al modelo o al controlador, lo deja registrado como el modelo con el cual se comunicara y apunta con la variable controller al controlador asignado, enviándole al mismo su identificación para que el controlador establezca en su variable view el identificador de la vista y así puedan operar conjuntamente. El responsable de deshacer estas conexiones, seguirá siendo la vista, quitándose a sí misma como dependiente del modelo y liberando al controlador.

Diagrama de secuencia del patrón MVC

Ø El usuario activa el evento.

Ø El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque también puede llamar directamente a la vista).

Ø El modelo (si es necesario) llama a la vista para su actualización.

Ø Para cumplir con la actualización la Vista puede solicitar datos al Modelo.

Ø El Controlador recibe el control.

Objetivo

• Aislar los cambios de la interfaz gráfica de usuario y evitar que estos cambios impliquen cambiar la lógica de dominio de la aplicación.

• Reducir la distancia humano-máquina y facilitar los cambios de la interfaz de usuario.

Ventajas

Ø La implementación se realiza de forma modular.

Ø Clara separación entre interfaz, lógica de negocio y de presentación.

Ø Sus vistas muestran información actualizada siempre.

Ø Cualquier modificación que afecte al dominio, como aumentar métodos o datos contenidos, implica una modificación sólo en el modelo y las interfaces del mismo con las vistas

Ø Las modificaciones a las vistas no afectan al modelo de dominio

Ø Sencillez para crear distintas representaciones de los mismos datos

Ø Facilidad para la realización de pruebas unitarias de los componentes.

Ø Reutilización de los componentes.

Ø Simplicidad en el mantenimiento de los sistemas.

Ø Facilidad para desarrollar prototipos rápidos.

Ø Los desarrollos suelen ser más escalables.

Desventajas

Ø Está sujeto a una estructura predefinida, lo que a veces puede incrementar la complejidad del sistema. Hay problemas que son más difíciles de resolver respetando el patrón MVC

Ø Para desarrollar una aplicación bajo el patrón de diseño MVC es necesario una mayor dedicación en los tiempos iniciales del desarrollo (desarrollar un mayor número de clases).

Ø MVC requiere la existencia de una arquitectura inicial sobre la que se deben construir clases e interfaces para modificar y comunicar los módulos de una aplicación.

Ø MVC es un patrón de diseño orientado a objetos por lo que su implementación es sumamente costosa y difícil en lenguajes que no siguen este paradigma.

Ejemplo de MVC en aplicaciones web

Vista:

la página HTML

Controlador:

código que obtiene datos dinámicamente y genera el contenido HTML

Modelo:

la información almacenada en una base de datos o en XML junto con las reglas de negocio que transforman esa información (teniendo en cuenta las acciones de los usuarios)

MVC en java swing

Modelo:

• El modelo lo realiza el desarrollador

Vista:

• Conjunto de objetos de clases que heredan de java.awt.Component