控制器应该以MVC模式将数据传递给视图吗？

我经常使用ASP.NET MVC（以及其他基于Web的MVC实现），但这是我从未确定的事情：控制器和视图是否应该通信？

当然，控制器应该选择要使用的视图，但是我的意思是控制器应该将数据传递给视图吗？我认为，如果视图期望来自控制器的数据，则它们将有效地捆绑在一起（一对控制器）。相反，我通常让视图与模型本身进行通信，并且独立于任何控制器。

我有正确的方法吗？还是这是没有一个正确答案的情况？在Web和其他环境中工作时答案是否会改变？当您具有强类型视图的概念（例如在ASP.NET MVC中）时，答案是否会改变？

控制器准备数据，这些数据将进一步传递给视图以进行渲染/显示。它还通过发布-订阅机制或类似机制接受用户输入数据。查看Wikipedia或Martin Fowler网站上的第一个图表，以获取有关MVC的更多信息。

如果视图需要来自控制器的数据，则它们将有效地捆绑在一起（（控制器，视图）对）。

尽管视图通常接受数据，但在大多数MVC框架中，它并不依赖于特定的控制器。例如，JavaServer Faces家族就是例外。一般来说，Rails，Django或Spring MVC之类的框架允许您通过将数据（上下文，通常是map / dictionary / bag）传递到视图（其中视图是模板视图模式的实现）来将视图与控制器分离。

当您具有强类型视图的概念（例如在ASP.NET MVC中）时，答案是否会改变？

编程语言是否为强类型对组织应用程序的方式没有影响。

我的团队会不时讨论您提出的问题。我们讨论两种方法，都有其优点和缺点。

第一种观点认为，控制器可以通过以下模式来更新视图。它同时监听GUI和模型事件。发生GUI事件时，它将在模型中执行所需的操作，从而触发并触发事件。现在，控制器通常使用所需的数据更新视图。

第二种方法认为，视图本身正在侦听模型事件，并使用附加到事件或通过查询模型的数据来更新自身。

在第一种方法中，您将为控制器提供更多功能，该控制器实际上可以控制应用程序中正在进行的所有操作。有权根据他手中发生的事件来决定应以哪种方式更新视图，并以此保持视图的纯正。但是，正如您所说，这样可以将视图和控制器耦合在一起。

在第二个中，您将它们解耦，但是您的视图实际上是以某种方式控制自己的。