Model view controller MVC元素之间的关系

有人能解释一下画在这张图上的MVC元素（与活动模型）之间的关系吗

我是这样看的：

控制器→ 模型-由控制器更改的模型数据

模型→ 视图-模型通知视图有关更改的信息

看法→ 模型-视图从模型中获取数据

看法→ 控制器-视图通知控制器用户的操作（例如，按下按钮）

控制器→ 视图-但是，正如我所认为的，这种关系是不必要的，并且与MVC关于独立于视图开发控制器的规则相矛盾：它应该通过模型进行交互

---

我认为模型和视图之间的关系是错误的（至少是实体关系）。在MVC模式中，我认为一切都是通过控制器进行的。因此，在视图中，用户选择他想要查看的数据。该请求被发送到控制器。控制器将获取模型中的数据，模型将返回请求的数据。然后，控制器将其发送回视图，视图将其输出给用户。

MVC是一个相当广泛的主题，这种模式有许多变体和许多实现。我见过一些解决方案，其中控制器的职责之一是创建一个视图实例，并附加相关模型。这可能就是你要找的亲戚

---

另一件事——在我看来，独立于视图的控制器的存在在现实生活场景中是一个神话。迟早，您需要提供一种功能，该功能明确地收紧了视图-控制器的关系，并且在没有特定视图的情况下是不可用的（或完全不同的）。此外，更有效的做法是接受不同类型的视图表现不同的事实，并通过构建定制的控制器将其转化为优势，而不是假装我们可以用一个控制器处理用户交互的各个方面

至于您突出显示的控制器->视图关系

• 控制器需要能够选择显示的适当视图

AFAIK，这是控制器与视图的唯一关系（除了视图将消息路由到控制器）。MVC与MVVM/MVP有点不同，因为每个控制器不一定只有一个视图。例如，您可以有一个用户控制器，您可以有一个用于显示信息的视图、一个用于编辑用户的视图和一个用于添加用户的视图。对于其他两种方法，视图和ViewModels或Presenter之间存在一对一的关系

• 控制器独立于视图不是神话

也许我在其他场景中没有充分使用MVC，但我始终保持控制器独立于视图。事实上，如果您的控制器中有任何视图代码（即带有ListBoxEventArgs的函数、引用视图组件等），那么您还没有实现此模式的目标，即将视图与逻辑和模型分离。我相信ASP.NET MVC通过一些类来管理跟踪启动的视图，从而使视图完全独立于控制器。该类可用于所有控制器（通过继承，但依赖项注入也很好），然后每个控制器仅使用该类选择要显示的视图。可以使用常量或字符串来选择视图（事实上，我认为甚至可以不带参数，根据方法名来选择它们）

---

查看->控制器关系

使用ASP.NET MVC，视图也独立于控制器，因为事件通过url路由到控制器。然而。在其他非web的情况下，通过直接调用代码隐藏中的控制器方法将事件转发给控制器是可以的

---

实施细节

在我的博客上，我写了一篇文章，介绍了MVC的实现，应该有助于回答您的问题

---

就我个人而言，我认为您的图表中显示的MVC类型在今天并不像过去那样经常使用，并且可能很难找到使用这些关系的示例。原因是，如果视图能够与模型对话，那么我认为开发人员会选择MVP或MVVM（并使用视图模型）而不是MVC。我能想到的唯一一种情况是视图无法与模型持续对话的情况是在服务器-客户机情况下。在这种情况下，有很多流行的MVC框架，比如ASP.NET MVC，今天仍然很流行

哦，对不起，我忘了指定，我写的是关于活动模型的。你刚才说的看起来像是被动模型。好的，我在想这个。我举了一个例子，说明在控制器中放置视图代码是很有诱惑力的——如果您有一个需要显示的通用消息框。有一种愿望，就是在你的控制器中做一些类似MessageBox.Show（…）的事情。只需几行代码，就可以在视图管理器中创建一个消息框视图（视图管理器是控制器用于选择视图的方法）。