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