3

我最近阅读了这篇文章，这导致了一系列其他文章似乎都暗示了相同的想法：模型做所有事情，视图应该能够直接与模型通信，反之亦然，而控制器则不受影响。然而，所有显示的示例都相当简单，没有一个真正显示任何人如何尝试实现对请求/响应周期的完整处理的示例，这让我想知道“模型是否应该负责处理请求（即$_GET、$_POST 等）本身？” 和“控制器是否应该仅作为传递来实例化必要的模型并将模型传递给视图？”。（事实上​​我发现了一个极端的例子，就是在模型中嵌入一个 Zend_Form 对象）

根据我对 Fowler 对 MVC 和控制器的一般看法的阅读，乍一看似乎控制器层越薄越好。但是后来我花时间回顾并研究了他对 MVC 和 Front Controller 的说法（这只是把水弄得一团糟，因为这两种模式都定义了控制器），现在我的直觉表明 Zend_Framework 在实现这两种模式时，实际上已经创建了一个复合对象，它执行 MVC 中的 Controller 和 Front Controller（或某些类似）中的 Command 对象的功能。

所以我想知道在他们的应用程序中实现了类似模式的其他人的一般意见是什么——你是完全在控制器层内处理请求，还是让模型知道请求并直接在模型内处理参数？

4

2 回答 2

4

我的第一个想法是避免在模型中处理任何类型的请求。那是控制器的工作。原因如下：假设您有一个模型可以处理您的请求（GET 或 POST）。这种结构最初可能会运作良好。现在，假设您想添加某种 AJAX 功能或为您的系统建立一个服务接口。现在您接受的不仅仅是简单的 GET/POST，即 JSON 或 XML，您的模型将必须区分每种请求类型并知道如何解析它们。我相信这会破坏模型代码的很多简单性和清晰度。我同意控制器层应该很薄，但它也应该有角色和专业知识。对我来说，控制器的专长是：

  1. 处理传入请求
  2. 向模型传递数据
  3. 从模型请求/接受数据
  4. 将数据的模型传递给视图

我对视图应该对模型了解多少犹豫不决。有些人建议模型直接进入视图，但我认为这是脆弱的耦合。它经常导致视图中的逻辑。此外，如果您正在处理一个项目，其中处理视图的团队成员不像主要开发人员那样精通编程，这会给他们带来很大的负担来跟上变化。我倾向于以中立的结构将我交给我的视图的数据打包，而不是交出完整的模型。

我对 MVC 的解释大多是务实的。该模型的工作是对您正在处理的领域进行建模，并且不应该关心数据的来源。我经常构建模型代码，假设它可以在 Web 应用程序之外的命令行应用程序或桌面应用程序中使用。这种联合很少发生，但它导致了每一层的明确目的。控制器的工作是在相关方之间移动数据，无论是客户端请求、模型还是视图。控制器应该有很少的域逻辑，但这并不意味着它没有任何代码。最后，视图应该看起来很漂亮。希望有帮助。

于 2009-01-12T02:42:18.230 回答
3

处理用户指令/输入（如 HTTP 请求）是控制器的工作。模型用于工作/操作/获取数据，视图用于向用户显示结果。这意味着视图和模型之间的连接大多数时候是控制器的职责。

于 2009-01-11T10:30:34.573 回答