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
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
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.
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
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
Controlador:
•
El controlador es el thread de tratamiento de
eventos, que captura y propaga los eventos a la vista y al modelo Clases de
tratamiento de los eventos (a veces como clases anónimas) que implementan
interfaces de tipo EventListener (ActionListener, MouseListener,
WindowListener, etc.
