¿Debería el controlador pasar datos a una vista en el patrón MVC?

Trabajo con ASP.NET MVC (y otras implementaciones de MVC basadas en web) con bastante frecuencia, pero esto es algo de lo que nunca he estado seguro: ¿deberían comunicarse el controlador y la vista?

Por supuesto, el controlador debe elegir qué vista usar, pero ¿a qué me refiero debe pasar el controlador a la vista? En mi opinión, si la vista espera datos del controlador, entonces están efectivamente unidos como un par (controlador, vista). En cambio, normalmente tengo la vista comunicarse con el modelo en sí y ser independiente de cualquier controlador.

¿Tengo el enfoque correcto, o es este un caso de que no hay una respuesta correcta? ¿La respuesta cambia cuando se trabaja en la web en comparación con otros entornos? ¿La respuesta cambia cuando tienes el concepto de una vista fuertemente tipada (como en ASP.NET MVC) o no?

El controlador prepara los datos que luego se pasarán a la vista para su representación / visualización. También acepta datos de entrada del usuario a través de un mecanismo de publicación-suscripción o similar. Consulte el primer diagrama en Wikipedia o el sitio web de Martin Fowler para obtener más información sobre MVC.

si la vista espera datos del controlador, entonces están efectivamente unidos como un par (controlador, vista).

Si bien una vista generalmente acepta datos, en la mayoría de los marcos MVC, no depende de controladores específicos. Las excepciones son, por ejemplo, la familia JavaServer Faces. En términos generales, los marcos como Rails, Django o Spring MVC le permiten desacoplar vistas de los controladores al pasar datos (el contexto, comúnmente un mapa / diccionario / bolsa) a una vista (donde una vista es una implementación del patrón de vista de plantilla ).

¿La respuesta cambia cuando tienes el concepto de una vista fuertemente tipada (como en ASP.NET MVC) o no?

Si su lenguaje de programación está o no fuertemente tipeado no tiene influencia en la forma en que organiza su aplicación.

La pregunta que está planteando se discute en mi equipo de vez en cuando. Discutimos sobre dos enfoques, que tienen sus contras y sus pros.

El primero, argumenta que el controlador puede actualizar la vista mediante el siguiente patrón. Escucha tanto la GUI como los eventos modelo. Cuando ocurre un evento de GUI, ejecuta la acción requerida en el modelo, que a su vez se dispara y evento. Ahora el controlador suele actualizar la vista con los datos requeridos.

El segundo enfoque, argumenta que la vista misma está escuchando los eventos del modelo y se actualiza con los datos que se adjuntan al evento o al consultar el modelo.

En el primer enfoque, tiene más potencia para el controlador que realmente controla todo lo que sucede en su aplicación. El poder de decidir de qué manera la vista debe actualizarse de acuerdo con el evento que está en sus manos y de esta manera usted mantiene su vista pura. Sin embargo, como dijiste, de esta manera tienes tu vista y controlador acoplados.

En el segundo, los está desacoplando, pero su vista en realidad se está controlando de alguna manera.