在MVC中处理$ _POST数据的正确方法是什么? [英] What is the right way to handle $_POST data in MVC?
问题描述
我在我的PHP系统中有常见的MVC情况: Controller
收到来自 View
code> $ _ POST 数据。现在我有三种方法来处理数据:
a) Controller
只调用 Model
和 Model
处理 $ _ POST
数据。
b) Controller
将 $ _ POST
数据转换为变量并传递给 Model
。
c)控制器
将 $ _ POST
转换为 Model
的域对象,并且只将对象传递给 Model
。
目前,我选择了A,但我相信它是错误的,所以我想使用选项C.
所以,根据MVC,什么是正确的方式来处理 $ _ POST
数据?
EDIT
EDIT 2 通常,相同的 Controller
句柄请求从浏览器,Web服务,离线应用程序等,或每个都有自己的控制器
?最好的选择是使用#2 方法,有些更改。
我会这样写: p>
public function postLogin($ request)
{
$ service = $ this-> serviceFactory->建立('Recognition');
$ service-> authenticate($ request-> getParam('username'),
$ request-> getParam('password'));
}
//是的,这是整个方法
实际创建变量,如果你已经使用像请求
实例来抽象用户的输入。
此外,您可能需要替换
Request :: getParam()
方法与Request :: getPost()
- 虽然我得出结论,在一个正确结构化的应用程序,GET
和POST
参数不应共享同一个名称。
您在代码片段中看到的 serviceFactory
将是一个在控制器和视图实例中注入的对象。它将允许您在控制器和视图之间共享相同的服务实例。
它负责创建服务 (其中包含应用程序逻辑,而将域业务逻辑保留在域对象),这有助于您从表示层中分离域实体和存储抽象之间的交互。
-
Controller仅调用Model和Model处理$ _POST数据。 p>
在MVC和MVC启发的设计模式中,模型应该不知道用户界面和表示层。 PHP中的
$ _ POST
变量是一个超全局 a>。
如果您在模型层中使用它,您的代码将绑定到Web界面,甚至特定的请求方法。
-
Controller将$ _POST数据转换为Model对象,并只将对象传递给Model
不完全确定你的意思。似乎你在谈论一个抽象的实例化,它将包含用户的请求。但在这种情况下,控制器负责实例化/创建所述结构,这将违反 SRP 。
结束注释:
你必须理解的一件事是,基于Web的MVC应用程序,您的应用程序的 User 是浏览器。不是你。浏览器发送请求,由路由机制处理并由控制器传播。而视图会对您的浏览器产生响应 。
另一件事是:Model既不是类也不是对象。 模型是一个图层。
更新
一般来说,同一个控制器处理来自浏览器,Web服务,离线应用程序等的请求,或者每个都有自己的Controller?
你应该能够有单个控制器,处理所有的应用程序形式。但这只是在条件,你实际上使用相同的应用程序所有3个用例。
这样做有两个条件:
- 您需要抽象
请求
实例,控制器接收 - 视图应在控制器外部实例化
这样,您可以使用一个应用程序来满足所有要求。每个变体都有不同的是引导阶段,在其中创建请求
实例并选择适当的视图。
在你描述的情况下,更改部分实际上是视图,因为REST或SOAP服务将产生与普通Web应用程序不同的响应。
I have the common MVC situation in my PHP system: the Controller
receive a request from the View
containing $_POST
data. Now I have three ways to handle the data:
a) The Controller
only calls the Model
and the Model
handle the $_POST
data.
b) The Controller
transforms the $_POST
data into variables and pass them to Model
.
c) The Controller
transforms $_POST
data into a Model
's domain object and only pass the object to Model
.
Currently, I am following option A, but I believe it is wrong, so I am thinking of using option C.
So, according to MVC, what is the right way to handle $_POST
data?
EDIT At the moment, I'm not using any MVC framework.
EDIT 2 Generally, the same Controller
handles request from a browser, a web service, an offline application, etc, or each one has it own Controller
?
The best option is to use #2 approach, with some alterations.
I would write it as something like this:
public function postLogin( $request )
{
$service = $this->serviceFactory->build('Recognition');
$service->authenticate( $request->getParam('username'),
$request->getParam('password') );
}
// Yes, that's the whole method
There is no need to actually create variables, if you have used something like a Request
instance to abstract the user's input.
Also, you might want to replace the
Request::getParam()
method with something likeRequest::getPost()
- although I have come to the conclusion that, in a correctly structured application, theGET
andPOST
parameters should not share same name.
The serviceFactory
which you see in the code snippet would be an object that you inject in both controller and view instance. It would let you share same service instances between controllers and views.
It is responsible for creation of services (which would contain the application logic, while leaving the domain business logic in the domain objects), which helps you isolate the interaction between domain entities and storage abstractions from the presentation layer.
About the other options:
The Controller only calls the Model and the Model handle the $_POST data.
In the MVC and MVC-inspired design patterns the model should be aware of neither the user interface nor of the presentation layer as whole. The
$_POST
variable in PHP is a superglobal.If you use it with model layer, your code becomes bound to the web interface and even the specific request method.
The Controller transforms $_POST data into a Model's object and only pass the object to Model
Not entirely sure what you meant with this. Seems you were talking about instantiation of an abstraction, which would contain the user's request. But in this case controller becomes responsible for instantiation/creation of said structure, which would violate SRP.
Closing notes:
One thing you must understand is that, in context of web based MVC applications, the User of your application is the browser. Not you. Browser sends the request, which is handled by routing mechanism and disseminated by controller. And view produces the response to your browser.
And the other thing is: Model is neither a class nor an object. Model is a layer.
Update
Generally, the same Controller handles request from a browser, a web service, an offline application, etc, or each one has it own Controller?
You should be able to have single controller, that deals with all the forms of application. But that is only on the condition, you are actually using same application for all 3 use-cases.
To do so there are two conditions:
- you need to abstract the
Request
instance, that controller receives - the view should be instantiated outside the controller
This way you can have one application to fulfill all the requirements. Only thing, that each variant has different, is the bootstrap stage, where you create the Request
instance and select the proper view.
In the situation, that you described, the changing part would actually be the view, since a REST or SOAP service would be expected to produce a different response than an ordinary web application.
这篇关于在MVC中处理$ _POST数据的正确方法是什么?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!