Comunicación dentro de la tríada MVC.
El modelo, la vista y el controlador tiene que comunicarse unos con otros para lograr una interacción coherente con el usuario. La comunicación entre la vista y el controlador asociado es directa y unidireccional porque la vista y el controlador están diseñados específicamente para trabajar juntos. Por otra parte los modelos se comunican de una manera más complicada.
Figura 1 Relaciones entre los tres componentes de MVC
El modelo pasivo.
En el caso más simple no es necesario que el modelo tome parte en la triada MVC. Un editor de texto simple WYSIWYG (lo que ves es lo que hay) es un buen ejemplo. La propiedad central del editor que siempre se ve es el texto como si estuviera en el papel. La vista debe ser informada de cada cambio que ocurra en el texto para que pueda actualizar correctamente la pantalla. En este caso el modelo no necesita tomar responsabilidad para informar de los cambios a la vista porque estos cambios ocurren sólo a solicitud del usuario. El controlador puede asumir la responsabilidad de notificar a la vista porque es quién procesa las entradas del usuario. Simplemente puede notificar a la vista que algo ha cambiado o la vista puede solicitar el estado actual del texto. En cualquier caso el modelo es un contenedor completamente pasivo de los datos que son manipulados por la vista y el controlador. Adiciona, elimina y remplaza subcadenas a demanda del controlador y devuelve subcadenas a demanda de la vista. El modelo es totalmente inconsciente de la existencia de la vista y del controlador.
El modelo activo.
No siempre el modelo toma este papel de pasivo. Cuando el modelo cambia su estado sin la intervención del controlador se dice que éste es activo. Esto puede ocurrir cuando entes ajenos cambian los datos y estos cambios deben reflejarse automáticamente en todas las vistas. Como sólo el modelo puede llevar la cuenta de todos los cambios de estado que ocurren, tiene que existir un canal de comunicación hacia la vista. Sin embargo, esta comunicación no debe establecer dependencias entre el modelo y las vistas, porque uno de los mayores beneficios de este paradigma es la separación y asilamiento entre el modelo y las vistas y el controlador. Para suplir esta necesidad, debe existir un objeto global que almacene las dependencias tales como ente el modelo y la vista. Esta clase de objeto global es normalmente un diccionario donde las llaves almacenan todos los objetos que tienen registradas dependencias, y los valores una lista con cada uno de los objetos que dependen de la llave en cuestión.
Esto puede ser perfectamente implementado mediante el patrón Observer, el cual provee un mecanismo para notificar a otros objetos sobre cambios de estado sin introducir dependencias directas entre dichos objetos. Las vistas individuales implementan la interfaz Observer y se registran en el modelo. El modelo lleva, en el diccionario antes mencionado, el control de cuantos objetos que implementen la interfaz Observer, y aquí es donde realmente está la importancia de este patrón porque no necesita saber de quienes son en realidad, solo que sean Observers. A esta forma también se le conoce como política de subscripción: los objetos se subscriben y son notificados en el momento necesario. Incluso si hiciera falta que el controlador recibiera notificación de los cambios del modelo, lo único que tendría que hacer dicho controlador implementar la interfaz Observer. En situaciones donde hay muchas vistas, es conveniente definir varios objetos para que las vistas se registren, permitiendo así que cada vista se subscriba a los tipos de cambios que le puedan resultar relevantes.
Figura 1 El modelo activo utilizando un Observer.
Comunicación Vista-Controlador.
A diferencia del modelo, que no está directamente conectado a múltiples tríadas MVC, cada vista está asociada con un único controlador y viceversa, variables instancias de cada una mantienen esta relación. Ambos tienen que comunicarse con el modelo, cada una tiene una instancia del objeto modelo. Así, aunque el modelo está limitado a enviar mensajes sobre los cambios de sí mismo, tanto la vista como el controlador pueden mandarse mensajes directamente entre ellos y cada uno a su modelo.
Continuará…
Fuentes consultadas:
http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html