El patrón arquitectónico MVC (Model-View-Controller) es, en la actualidad, un estándar muy asentado para el desarrollo de sistemas software que precisan interactuar con personas y que, por tanto, entre sus componentes existe una interfaz de usuario. Todo ingeniero de software conoce este patrón y en la red es posible encontrar infinidad de artículos explicándolo. En esta breve entrada solamente se ofrece una visión histórica del mismo y, sobre todo, se destacan las ventajas que aporta al desarrollo de aplicaciones.
Cómo surge el patrón MVC
El primer documento en que se habla de la separación de los elementos de un sistema software en un modelo de ordenador, un software controlador y una vista manipulable por el usuario surge en los Xerox PARC (Palo Alto Research Center) en 1978 en The original MVC reports, mencionándose un componen adicional, llamado Editor, que forma parte de la vista.
Durante el desarrollo de una aplicación (por parte de un científico visitante que pasaba una temporada en el PARC) se hizo patente la necesidad de buscar una solución general al problema que planteaba el control de un conjunto de datos grande y complejo por parte de un usuario. El objetivo era adaptar el modelo de ordenador de esos datos al modelo mental de la persona que debía usarlos, interponiendo los componentes software apropiados para ello.
La aplicación a desarrollar era un sistema de planificación y en él se empleaban cuatro metáforas: thing, model, view y editor, extrapolación del objeto de interés para el usuario, la abstracción de ese objeto en forma de datos en un ordenador, una o más posibles representaciones de dicho objeto y la interfaz entre el usuario y esas vistas, respectivamente.
Tras un proceso de refinamiento se definió el modelo como una representación del conocimiento con el que debe trabajar el sistema, la vista como una representación visual de ese modelo y se introduce el controlador como el enlace entre el usuario y el sistema. Estas ideas se plasman en un documento publicado el 10 de diciembre de 1979 con el título Model-Views-Controllers, naciendo el acrónimo MVC.
La primera implementación de MVC como patrón arquitectónico, más allá de la aplicación puntual que le dio origen, se efectuó en el propio PARC para la librería Smalltalk-80. A partir de ese momento comenzó su popularización y se extendió su uso, con independencia de plataformas, lenguajes de programación e incluso arquitectura del sistema a desarrollar.
Beneficios que aporta MVC al diseño de sistemas software
Es necesario partir de la base de que este patrón es aplicable exclusivamente a sistemas software en los que se precisa interacción por parte del usuario, no teniendo sentido fuera de dicho contexto.
Un mismo sistema puede contar con múltiples vistas, dependiendo por ejemplo del tipo de usuario que lo utiliza. Una aplicación bancaria, por poner un ejemplo, ofrece una vista especializada al cliente que accede a través de la Web desde su ordenador, distinta de la que obtiene el trabajador que atiende físicamente en la oficina a los clientes. El sistema es el mismo, pero las vistas obviamente no.
Además las vistas suelen evolucionar con el tiempo, adaptándose a los nuevos toolkit de los sistemas operativos, a nuevos dispositivos como los teléfonos móviles o sencillamente adaptándose a nuevas necesidades. En contraposición, el modelo interno del sistema suele mantenerse estable a lo largo del tiempo y raramente cambia una vez concluida la fase de desarrollo. Podría decirse que el modelo es la esencia invariable del sistema y es la plasmación del conocimiento que se tiene del dominio en una estructura interpretable por un ordenador.
Diseñar (y especialmente mantener) un sistema en el que unos componentes cambian dinámicamente durante la ejecución y/o a lo largo del tiempo y deben comunicarse con otros invariables representa una cierta dificultad. En este contexto el patrón MVC facilita el desacoplamiento de dichos componentes, de forma que es posible cambiar de vista con gran sencillez sin necesidad de alterar en ningún sentido el modelo.
Para que el modelo pueda permanecer inmutable a lo largo del tiempo es indispensable que esté completamente desconectado del mundo exterior, es decir, el modelo no tiene conocimiento alguno sobre la vista ni acerca del controlador. Esto se consigue principalmente mediante la aplicación de dos patrones software bien conocidos: el patrón estrategia y el patrón observador.
El patrón observador permite al modelo notificar hacia el exterior los cambios que se produzcan en el estado del sistema, pero sin conocer detalle alguno sobre el componente al que está notificando. Esto hace posible que el controlador y la vista reciban mensajes desde el modelo sin que éste cuente con un conocimiento explícito sobre aquellos.
Aunque la arquitectura MVC no lo establece explícitamente, el desacoplamiento entre el modelo y los demás componentes del sistema se incrementa si estos últimos tampoco tienen un conocimiento directo del primero, para lo cual se recurre al citado patrón estrategia. Lo que controlador y vista tienen es una interfaz de acceso al modelo, no una referencia directa a los objetos que lo componen.
Cabe preguntarse, si el modelo no tiene conocimiento de vista ni controlador y éstos no conocen directamente el modelo, ¿cómo es posible que el sistema opere como un todo? Por convención cuando el sistema se pone en marcha crea el controlador y deja en sus manos la creación del modelo y la vista o vistas que pudieran existir, estableciendo las conexiones adecuadas entre ellos.
En resumen, el patrón arquitectónico MVC favorece el diseño de sistemas software en base a componentes que tienen una alta cohesión: únicamente el modelo gestiona el estado del sistema, solamente la vista genera representaciones visuales de dicho estado etc.; y mantienen un elevado grado de desacoplamiento, haciendo posible la modificación e incluso sustitución de cualquiera de ellos sin afectar al resto. Todo ello contribuye a simplificar el diseño de aplicaciones complejas que, de otra forma, resultarían mucho más difíciles de abordar y mantener.