Zend_Framework-在何处放置$ _GET和$ _POST(HTTP请求)处理? [英] Zend_Framework- Where to Place $_GET and $_POST (HTTP Request) handling?
问题描述
I recently read this post which led to a series of other posts that all seem to suggest the same idea: Models do everything, the View should be able to communicate directly with the model and vice versa all while the Controller stays out of the way. However, all of the examples shown are fairly simplistic and none really show an example of how anyone has tried to implement full handling of of a request / response cycle, which got me to wondering "should the model be responsible for handling the request (ie $_GET, $_POST, etc) itself?" and "should the controller only operate as a pass-through to instantiate the necessary model(s) and pass the model(s) to the view?". (In fact I found one example taken the extreme of embedding a Zend_Form object in the model)
从我阅读的Fowler关于MVC以及一般来说控制器的内容看，乍一看，控制器层越薄越好.但是后来我花时间回顾并研究了他对MVC和Front Controller的看法(由于这两种模式都定义了控制器，这使人们感到困惑)，现在我的直觉表明Zend_Framework在实现这两种模式时实际上已经创建了一个复合对象，它执行MVC中的Controller功能以及Front Controller中的Command对象(或某些类似功能)的功能.
From my reading of what Fowler says about MVC and just controller's in general it seems at first glance that the thinner the controller layer the better. But then I took the time to back through and study what he says about both MVC and Front Controller (which just muddies the waters because both patterns define controllers) and now my instincts suggest that Zend_Framework in implementing both of these patterns, has actually created a composite object that performs the functions of a Controller in MVC and those of a Command object in Front Controller (or some such).
因此，我想知道那些在其应用程序中实现了类似模式的其他人的一般看法-您是完全在控制器层内处理请求还是让模型知道请求并直接在内部处理参数该模型?
So I'm wondering what the general opinions would be of others who have implemented similar patterns in their apps - do you handle the request entirely within the controller layer or do you make the model aware of the request and handle parameters directly within the model?
推荐答案
我的第一个想法是避免处理模型中的任何类型的请求.那就是控制器的工作.原因如下:假设您有一个处理请求(GET或POST)的模型.该结构最初可能会运作良好.现在，假设您要添加某种AJAX功能或为系统建立服务接口.既然您接受的不仅仅是简单的GET/POST(即JSON或XML)，您的模型就必须区分每种请求类型，并知道如何解析它们.我相信这会破坏模型代码的许多简单性和清晰度.我同意控制器层应该很薄，但是它也应该具有作用和专业知识.对我来说，控制器的专业知识是:
My first thought is to avoid handling any sort of request in the model. That is the job of the controller. Here is why: suppose you have a model that does handle your requests (GET or POST). That structure will likely work well initially. Now, suppose you want to add some sort of AJAX functionality or put up a service interface to your system. Now that you accept more than simple GET/POST, i.e. JSON or XML, your model will have to distinguish between each request type and know how to parse them. I believe that destroys a lot of simplicity and clarity of the model code. I agree that the controller layer should be thin, but it should also have a role and an expertise. For me a controllers expertise is to:
- 处理传入请求
- 将数据传递到模型
- 从模型请求/接受数据
- 将数据模型传递给视图
我对视图应该了解的模型多少持怀疑态度.有人建议模型直接进入视野，但我认为这是脆弱的耦合.它经常导致视图中的逻辑.同样，如果您正在从事一个项目，而在视图上工作的团队成员不像主要开发人员那样精通编程，那么这将给他们带来很大的负担以跟上更改的步伐.我倾向于以中立的结构将提交给我的视图的数据打包，而不是提交完整的模型.
I vacillate on how much the view should know about the model. Some people recommend the model go straight into the view, but I think that is fragile coupling. It frequently leads to logic in the view. Also, if you are working on a project where the team members working on the view are not as programming savvy as the main developers it puts a large burden on them to keep up with changes. I tend to package the data I hand to my views in a neutral structure instead of handing over the full models.
我对MVC的解释大多是实用的.模型的工作是对正在使用的域进行 建模，并且不必关心数据来自何处.我经常假设模型代码可以在Web应用程序之外的命令行应用程序或桌面应用程序中使用，以此来构建模型代码.这种结合很少发生，但可以明确每一层的目的.控制器的工作是在涉及的各方(客户请求，模型或视图)之间移动数据.控制器应该只有很少的域逻辑，但这并不意味着它没有任何代码.最后，视图应该看起来很漂亮.希望能有所帮助.
My interpretation of MVC is mostly pragmatic. The model's job is to model the domain you are working on and should not care where the data comes from. I frequently structure model code with the assumption that it could be used outside of the web application in perhaps a command line application or a desktop application. That sort of union rarely happens, but it leads to clear purpose of each layer. The controllers job is to move data between involved parties, be they client requests, the models, or the view. The controller should have very little domain logic, but that doesn't mean it doesn't have any code. Finally, the view should just look pretty. Hope that helps.
这篇关于Zend_Framework-在何处放置$ _GET和$ _POST(HTTP请求)处理?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
