Interesante
, hace poco tuve la misma discusión y al final hice una encuesta entre colegas que saben más y mi conclusión es (tengo este tema agendado para hacer un post al respecto):
Por defecto, el MVC estándar: es C -> M y C -> V, es decir, el controller recibe las peticiones, decide si tiene que pedir información al Modelo, y luego pasar información a la Vista.
Este es el tradicional y clásico, así lo he corroborado también con colegas que usan otras arquitecturas, principalmente Java.
El punto es, el patrón dice más cosas que esto (lo anterior es lo esencial); también debería poder M -> V y V -> M (sustituir la flecha por "actualizar"), pero (aquí el dilema), los frameworks para la web basados en lenguajes de scriptings (no hablo de arquitecturas como Java o .Net) y
el famoso "stateless" (una vez que el servidor web entrega la página, se olvida de lo ocurrido) no sería posible que ni el Modelo ni la Vista actualizarse directamente.
Nota: si estamos en un entorno de escritorio y la aplicación corre constantemente, otro es el contexto y la comunicación MVC se puede hacer factible en todos los sentidos. De la misma forma si hablamos de una arquitectura como Java, ya que ellos cuentan con más herramientas, como ser, un servidor de aplicaciones, algo que nosotros no tenemos.
En mi caso particular, me acostumbré al "MVC tradicional" y usando Zend Framework (aunque la mayoría de los frameworks hacen lo mismo, incluyendo Ruby On Rails) no me estaba cuestionando más allá.
Ahora que tuve la misma discusión que están teniendo ustedes, lo que se me ocurrió en su momento (y de forma natural ya lo entendía así)
como forma de actualizar M<->V (hacia ambos sentidos) es que surjan
invocaciones Ajax que lo simulen (principalmente el caso M->V que debería ser una consulta periódica de la V al M para saber si este cambió).
Ese es mi breve resumen y humilde opinión (se aceptan opiniones opuestas con fundamento), pero me entra en duda ahora lo que dice el colega GatorV y cómo hace para que la V actualice el M
PD: hay muchas opiniones al respecto, algunos dice que el MVC que hacemos no es "puro" (por todo lo expuesto) y otros que el MVC no es la mejor solución para el ambiente web, etc, pero lo que quiero dejar en evidencia que esta discusión no es nueva y tampoco hay una sola respuesta / conclusión.