MVC:为什么我们需要"控制器",或者何时应该使用这种模式？

Question

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

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

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

client是一个GUI,它绑定到服务器,与用户交互,从用户向服务器发送命令.

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

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直接从模型中获取这些数据会发生什么不好的事情？

Answer 1

据我所知，“客户端-服务器”与 MVC 无关。

我是这样理解的：

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

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