14

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

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

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

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

我喜欢这种架构,但我不明白为什么人们真的需要在客户端服务器之间再增加一个媒介,这似乎是控制器

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

我将如何做到:

服务器包含以下项目:

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

客户端包含以下项目:

  • Appl核心:创建Data_receiver(连接到COM端口的)实例,Data_decoderData_core(引用Data_receiverData_decoder实例),还创建GUI简单日志窗口(引用Data_core);
  • GUI简单日志窗口:绑定到Data_core,即监听它发出的信号,并显示接收到的数据。

正如我所了解的有关 MVC 的内容,GUI 实际上不应该Data_core从. 但是如果 GUI 直接从模型中获取这些数据会发生什么坏事呢?

4

4 回答 4

2

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

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

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

于 2015-08-15T10:31:56.427 回答
1

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

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

从服务器代码中分离出一个控制器是很有用的从模型。

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

当您以测试驱动开发方式推动您的开发以分离成不同的部分时,它很有用,这样您就可以附加各种测试。

于 2012-12-02T19:58:05.820 回答
1

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

我是这样理解的:

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

它背后的想法是将视觉表示从逻辑中分离出来。因此,当您获取视图时,您不会复制逻辑。...因此,在您的情况下,您可能仅在客户端使用 MVC,并且您需要一个控制器,因为这就是所有魔术发生的地方。

于 2012-12-02T18:02:20.167 回答
-1

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

如果您通过以下几行,答案就很清楚了,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.

问候, Pavan.G

于 2012-12-03T09:21:44.683 回答