我最近读过这个帖子 http://blog.astrumfutura.com/archives/373-The-M-in-MVC-Why-Models-are-Misunderstood-and-Unappreciated.html这导致了一系列其他帖子似乎都提出了相同的想法：模型做所有事情，视图应该能够直接与模型通信，反之亦然，而控制器不介入。然而，显示的所有示例都相当简单，没有一个真正显示任何人如何尝试实现请求/响应周期的完整处理的示例，这让我想知道“模型是否应该负责处理请求（即$_GET、$_POST 等）本身？”以及“控制器是否应该仅作为传递来实例化必要的模型并将模型传递给视图？”。 （事实上，我发现一个极端的例子是在模型中嵌入 Zend_Form 对象）
从我阅读 Fowler 关于 MVC 和一般控制器的内容来看，乍一看似乎控制器层越薄越好。但后来我花时间回顾并研究了他关于 MVC 和 Front Controller 的说法（这只是把水搅浑了，因为这两种模式都定义了控制器），现在我的直觉表明 Zend_Framework 在实现这两种模式时，实际上创建了一个复合对象，执行 MVC 中控制器的功能和前端控制器（或类似的）中命令对象的功能。
所以我想知道在他们的应用程序中实现类似模式的其他人的一般意见是什么 - 您是否完全在控制器层内处理请求，或者您是否使模型意识到请求并直接在模型内处理参数？
我的第一个想法是避免在模型中处理任何类型的请求。这是控制器的工作。原因如下：假设您有一个模型可以处理您的请求（GET 或 POST）。这种结构最初可能会运作良好。现在，假设您想要添加某种 AJAX 功能或向系统添加一个服务接口。现在您接受的不仅仅是简单的 GET/POST，即 JSON 或 XML，您的模型将必须区分每种请求类型并知道如何解析它们。我相信这破坏了模型代码的很多简单性和清晰度。我同意控制器层应该很薄，但它也应该有一个角色和专业知识。对我来说，控制者的专业知识是：
- 处理传入请求
- 将数据传递给模型
- 请求/接受来自模型的数据
- 将数据的模型传递给视图
我对于视图应该了解模型的程度犹豫不决。有些人建议模型直接进入视图，但我认为这是脆弱的耦合。它经常导致视图中的逻辑。此外，如果您正在处理的项目中处理视图的团队成员不如主要开发人员那么精通编程，那么跟上变化就会给他们带来很大的负担。我倾向于将传递给视图的数据打包在中性结构中，而不是传递完整的模型。
我对 MVC 的解释主要是实用主义的。模型的工作是model您正在处理的域，不应该关心数据来自哪里。我经常构建模型代码，假设它可以在 Web 应用程序之外的命令行应用程序或桌面应用程序中使用。这种联合很少发生，但它会导致每一层都有明确的目的。控制器的工作是在相关各方之间移动数据，无论是客户端请求、模型还是视图。控制器应该有很少的域逻辑，但这并不意味着它没有任何代码。最后，景色应该看起来很漂亮。希望有帮助。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
