我最近读了this post这导致了一系列其他帖子似乎都在暗示相同的想法:模型做所有事情， View 应该能够直接与模型通信，反之亦然，而 Controller 不妨碍。然而，所有显示的示例都相当简单，没有一个真正显示任何人如何尝试实现请求/响应周期的完整处理的示例，这让我想知道“模型是否应该负责处理请求(即$_GET、$_POST 等)本身？”和“ Controller 是否应该仅作为传递来实例化必要的模型并将模型传递给 View ？”。 (事实上我发现了一个极端的例子，在模型中嵌入了一个 Zend_Form 对象)
从我读到 Fowler 所说的关于 MVC 和一般 Controller 的内容来看，乍一看似乎 Controller 层越薄越好。但是后来我花时间回顾并研究了他对 MVC 和 Front Controller 的看法(因为这两种模式都定义了 Controller ，所以这只会混淆水域)现在我的直觉表明 Zend_Framework 在实现这两种模式时，实际上已经创建了一个复合对象，执行 MVC 中 Controller 的功能和前端 Controller (或类似)中命令对象的功能。
所以我想知道其他在他们的应用程序中实现了类似模式的人的一般意见是什么——你是完全在 Controller 层处理请求，还是让模型知道请求并直接在 Controller 层处理参数该模型？
最佳答案
我的第一个想法是避免在模型中处理任何类型的请求。那是 Controller 的工作。原因如下:假设您有一个模型可以处理您的请求(GET 或 POST)。该结构最初可能会运作良好。现在，假设您想要添加某种 AJAX 功能或为您的系统建立一个服务接口(interface)。现在您接受的不仅仅是简单的 GET/POST，即 JSON 或 XML，您的模型将必须区分每种请求类型并知道如何解析它们。我相信这会破坏模型代码的简单性和清晰度。我同意 Controller 层应该很薄，但它也应该有作用和专长。对我来说， Controller 的专长是:
- 处理传入的请求
- 向模型传递数据
- 请求/接受来自模型的数据
- 将数据的模型传递给 View
我对 View 应该对模型了解多少犹豫不决。有些人建议模型直接进入 View ，但我认为这是脆弱的耦合。它经常导致 View 中的逻辑。此外，如果您正在处理一个项目，其中处理 View 的团队成员不像主要开发人员那样精通编程，这会给他们带来很大的负担以跟上变化。我倾向于将我提交给 View 的数据打包成一个中性结构，而不是提交完整的模型。
我对 MVC 的解释主要是务实的。模型的工作是对您正在处理的领域建模，不应该关心数据的来源。我经常构建模型代码，假设它可以在 Web 应用程序之外使用，可能在命令行应用程序或桌面应用程序中使用。这种联合很少发生，但它导致每一层都有明确的目的。 Controller 的工作是在相关方之间移动数据，无论是客户端请求、模型还是 View 。 Controller 应该只有很少的域逻辑，但这并不意味着它没有任何代码。最后， View 应该看起来很漂亮。希望有所帮助。
关于php - Zend_Framework- 在哪里放置 $_GET 和 $_POST(HTTP 请求)处理？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/432435/