MVC - Model View Controller

Si bien el patron MVC es algo de lo que actualmente se oye hablar hasta en la fila del supermercado, no quise dejar pasar la oportunidad de escribir sobr él en este blog, enonces el objetivo de éste es recoger algunos aspectos que puedan servir de introducción (y base para profundizar la lectura) a conceptos relacionados con dicho patrón.

Introducción

Este patrón es categorizado por M. Fowler como uno de los patrones para diseño de presentaciones web.

El patrón MVC de acuerdo con la visión de M. Fowler [1], es uno de los más citados (y a la vez el más criticado) de entre los patrones más conocidos. Su comienzo se da a finales de los ‘70 como un framework desarrollado por Trygve Reenskaug para la plataforma Smalltalk. Desde entonces ha desempeñado un papel fundamental en la mayoría de los frameworks para IU y en las diferentes líneas de pensamiento acerca del diseño de UI.

Como funciona?

Este patrón considera tres diferentes roles. El modelo es un objeto que representa información acerca del dominio, es un objeto no visual que contiene toda la información y el comportamiento que es utilizado por la UI. En una visión del modelo puramente OO se trata de un objeto dentro de modelo de dominio.
La vista representa como se expone el modelo a través de la UI. Por lo tanto, si nuestro modelo es un objeto cliente, nuestra vista puede ser un cuadro completo de controles UI o estructuras HTML que presentan la información obtenida del modelo. La vita se responsabiliza únicamente de mostrar información, cualquier cambio a la información es capturada por una tercera parte del patrón MVC, el controlador (controller).
El controlador toma las entradas de usuario, manipula el modelo, y causa que la vista se actualice de forma adecuada. De esta manera, la UI resulta en una combinación estratégica de la vista y el controlador.
M. Fowler [1], expone que encuentra en el patrón MVC dos separaciones principales: una separación de la presentación y el modelo y otra entre el controlador y la vista. Además expone que la separación entre la presentación y el modelo es una heurística fundamental del buen diseño del Software.Un punto importante en esta separación es la dirección de las dependencias: la presentación depende del modelo pero el modelo no depende de la presentación. M. Fowler [1], de hecho recomienda que la gente que trabaja desarrollando el modelo debería ser completamente independiente de lo que aquellos que desarrollan la presentación están usando, con el principio en que ambas partes simplifiquen sus actividades, y faciliten el desarrollo de nuevas capas de presentación en el futuro. Además redunda en que los cambios a la capa de presentación puedan realizarse sin tener impacto en el modelo.

Este principio introduce además un tema en común. Con una interfaz que contemple varias ventanas, donde un programador realice un cambio en el modelo, este cambio impactara seguramente en varias ventanas, para soportar esta situación sin agregar dependencias innecesarias, seguramente las vistas deben comportarse como observadores del modelo (patrón Observer de Gang of Four).

La segunda división, la separación entre la vista y el controlador, puede verse un poco menos importante [1], en la práctica normalmente se tiene un controlador por cada vista o conjunto de vistas, y muchas veces se da que esta separación no existe. Debe evaluarse su implementación en aquellos sistemas donde la separación sea indispensable y muy útil.

A todo esto, hasta aquí hemos visto los principios del patrón, además podemos abstraer fácilmente donde estarían alojados las vistas y el modelo, pero ¿Dónde va el controlador? La visión más común lo sitúa en algún lugar entre el modelo y la vista.

Cuando utilizarlo?
M. Fowler [1], sitúa el valor del patrón MVC justamente en las separaciones comentadas previamente. Situando además a la separación entre la presentación y el modelo como uno de los principios de diseño de software más importantes, destacando que la única vez que no se debe seguir es en los sistemas en los que el modelo no tiene el control del comportamiento real. Recomienda que tan pronto como encontremos lógica no visual es que deberemos de aplicar la separación. Además destaca que la separación entre la vista y el controlador tiene menor importancia, recomendando que se haga únicamente cuando sea realmente necesario.

Con el objetivo de profundizar la lectura sobre este tema y comprender como este patrón es aplicado en arquitecturas de sistemas basados en plataformas Microsoft, simplemente recomendar la lectura de la Application Architecture Guide en su última release Beta 2.0.

Fuente: [1] M. Fowler y colegas, Patterns of Enterprise Application Architecture, Addison Wesley, November, 2002, ch. 14, pp. 330-331.