MVC：为什么我们需要“控制器”，或者我们什么时候应该使用这种模式？答案

【问题标题】：MVC: why do we need "controller", or when should we use this pattern?MVC：为什么我们需要“控制器”，或者我们什么时候应该使用这种模式？
【发布时间】：2012-11-20 05:50:59
【问题描述】：

我已经阅读了很多关于 MVC 的出版物，但我仍然不能清楚地理解为什么我们需要“控制器”。

我通常在 client-server 模型中编写应用程序：

server 包含所有业务逻辑，它对 gui 一无所知。它完成了主要工作，并且尽可能便携。

client 是一个 GUI，它绑定到服务器，与用户交互，将命令从用户发送到 服务器。

我喜欢这种架构，但我不明白为什么人们真的需要在 client 和 server 之间增加一个媒介，它似乎是 controller ？

UPD： 简单示例：假设我们需要编写一些数据记录器。数据来自 COM 端口，通过某种协议进行编码。需要在一个简单的日志窗口中显示收到的消息。

我该怎么做：

服务器包含以下项目：

Data_receiver：实际上是从 COM 端口接收原始数据，但它是接口，所以我们可以创建另一个类来接收来自任何其他来源的数据；
Data_decoder：获取原始数据并返回解码后的消息，它也是接口，因此我们可以轻松更改编码协议；
Data_core：使用Data_receiver 和Data_decoder 的实例，向客户端发出信号。

客户端包含以下项目：

Appl核心：创建Data_receiver（连接到COM端口的那个）、Data_decoder和Data_core（引用Data_receiver和Data_decoder实例）的实例，还创建GUI简单日志窗口（参考Data_core）；
GUI 简单日志窗口：绑定到Data_core，即监听它发出的信号，并显示接收到的数据。

据我了解我所读到的有关 MVC 的内容，GUI 不应该实际接收来自 Data_core 的消息，因为 控制器 应该这样做，然后将数据传递给 GUI。但是如果 GUI 直接从 model 获取这些数据会发生什么坏事呢？

【问题讨论】：

我喜欢这个问题，只是因为没有人给出“你做错了”的答案。这意味着整个社区要么不知道这个问题的答案（不太可能），要么 MVC 和 MVVM 被夸大了，以至于像你这样的人认为他们是需要的，而事实上，有时它们会妨碍代码的可读性。
此外，像 MVVM 和 MVC 这样的模式是模式。这意味着当您编写 SOLID 代码时，它们出现在您的代码中。换句话说，如果您正在编写 SOLID 代码，但模式没有出现，那么您可能正在编写不需要这些模式的代码。
此外，在您的示例中，您的客户端和服务器都有控制器代码。示例：文本字段只是一个文本字段。应用于该文本字段的验证逻辑是 controller 代码。如果您发现自己没有重复该验证逻辑，那么您可能正在以 DRY 方式编写代码，这不需要真正的“控制器”类。另一方面，如果您有两个视图都对它们的文本字段执行相同的操作（将它们转换为整数，确保它们在 1-100 之间），您可能需要考虑子类化文本字段并添加控制器逻辑。
注意：我把这些写成 cmets 是因为我敢肯定有很多人会反对这种想法。因此，您应该对我所说的持保留态度，并考虑到许多开发人员认为真正的 MVVM 实现是未来的发展方向。
MVC 与你的产品是否是客户端-服务器无关。

标签： model-view-controller client-server application-design

【解决方案1】：

过去我曾多次问过自己同样的问题，最近我一直在阅读有关 JSP 模型 2 架构的信息，维基百科条目说明了以下内容。

关于 J2EE 平台中 Web 层技术的文献经常使用术语“模型 1”和“模型 2”而没有解释。这个术语源于 JSP 规范的早期草案，它描述了 JSP 页面的两种基本使用模式。虽然这些术语已从规范文档中消失，但它们仍然被普遍使用。模型 1 和模型 2 仅指的是（分别）不存在或存在控制器 servlet，该控制器 servlet 分派来自客户端层的请求并选择视图。

这基本上意味着 MVC 模式本身存在变化，因此您始终可以根据您的项目应用 MVC 或 MV 模式。然而，一个合适的 MVC 架构确实应该有一个控制器，因为模型和视图不应该直接相互通信。

【讨论】：

【解决方案2】：

“client-server”与 MVC 无关，afaik。

我是这样理解的：

Model 是您构建数据的方式。
View 是可见表示。（图形用户界面）
Controller 使用逻辑来控制视图和/或其他逻辑。

其背后的想法是将视觉表示与逻辑分开。因此，当您获取视图时，您不会复制逻辑。 ...所以在您的情况下，您可能只在客户端使用 MVC，并且您需要一个控制器，因为这就是所有魔法发生的地方。

【讨论】：

但是逻辑和视觉表示已经被客户端-服务器架构分开了：服务器有数据和逻辑，客户端代表数据。我更新了我的问题（添加了简单的应用程序示例），请以某种方式对其进行评论（其中应该是模型，应该是视图，应该是控制器）
我猜Data_core 是你的控制器。您创建的window 是视图。当你有多个窗口发生不同的事情时，MVC 架构就会启动，因为你的 Data_core 会变得非常复杂。因此，您将尝试创建只执行其相应视图的逻辑的控制器小岛。然后将所有控制器连接到 Data_core。

【解决方案3】：

在阅读您的客户端-服务器模式的详细信息时，我想到了MVVM 模式。当您希望执行单元测试时，最好将 VM（ViewModel）视为控制器。

按照您的模式，经典的客户端/服务器模式，控制器、模型和视图存在于您称为 Data_receiver、Data_decoder 和 Data_core 的服务器代码中。在您的“客户”中，您再次拥有一个控制器和视图。

从服务器代码中分离出一个控制器是很有用的来自模型的原始数据。

在遵循不要重复自己 (DRY) 原则时，您可能会注意到代码的服务器和客户端部分中都有控制器代码，您重复代码或职责。

当您以测试驱动开发方式推动您的开发时，将其分成不同的部分非常有用，这样您就可以附加各种测试。

【讨论】：

【解决方案4】：

迟到总比不到好我想纠正您对“为什么需要在客户端和服务器之间增加一层”的误解。

如果您通过以下几行，答案就很清楚了，MVC 是架构的三角模型。

View 向 Model 提出请求，Model 向 Controller 提出请求，Controller 处理它并发回给 View。

The Model is the way you structure your data.
The View is the visible representation. (GUI)
The Controller uses the logic to control the view and/or other logic.

问候，帕万.G

【讨论】：

感谢您的回答，但我已经阅读了有关“三角形模型”等的内容。我真的不清楚，为什么这么多人谈论它这么好。如果您能编写 MVC 方式来设计我在问题中提到的简单日志记录应用程序，我将不胜感激。