Question

我读过很多关于MVC的出版物，但我仍然无法清楚地理解为什么我们需要“控制器”。

我通常在客户端 - 服务器模型中编写应用程序：

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

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

我喜欢这种架构，我无法弄清楚为什么人们真的需要在客户端和服务器之间再添一个媒体，它们似乎是控制器？

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

我将如何制作：

服务器包含以下项目：

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

客户端包含以下内容：

Appl核心：创建Data_receiver的实例（连接到COM端口的实例），Data_decoder和Data_core（引用Data_receiver和{{1}实例），还创建GUI简单日志窗口（引用Data_decoder）;
GUI简单日志窗口：绑定到Data_core，即侦听它发出的信号，并显示接收的数据。

当我理解我所读到的关于MVC的内容时，GUI实际上不应该从Data_core接收消息，因为 controller 应该这样做，然后将数据传递给GUI。但是，如果GUI直接从模型中获取这些数据会发生什么不好的事情？

Answer 1

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

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

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

Answer 2

“客户端 - 服务器”与MVC无关，afaik。

我理解如下：

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

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

Answer 3

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

遵循您的模式，经典的客户端/服务器模式，Controller，Model和View存在于您调用Data_receiver，Data_decoder和Data_core的服务器代码中。在您的“客户端”中，您再次拥有一个控制器和视图。

从服务器代码中分离出一个控制器，它接收和解码来自COM的信号和数据，一个控制器传递的模型，并在数据库的路由中接收数据，一个编码和格式化的视图来自模型的原始数据。

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

当您以测试驱动开发方式推动开发以分离成不同的部分时，它非常有用，因此您可以附加各种测试。

Answer 4

迟到总比没有好，我想纠正你对“为什么需要在客户端和服务器之间再建一层。”的错误解释。

如果你仔细阅读以下几行，答案很清楚MVC是三角形的建筑模型。

查询请求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.

此致 Pavan.G

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

4 个答案: