php - 在 MVC 中处理 $_POST 数据的正确方法是什么？

Question

我的 PHP 系统中有常见的 MVC 情况:Controller 从 View 接收到包含 $_POST 数据的请求。现在我有三种方法来处理数据:

a) Controller 只调用 Model 而 Model 处理 $_POST 数据。
b) Controller 将 $_POST 数据转换为变量，并将它们传递给 Model。
c) Controller 将 $_POST 数据转换为 Model 的域对象，并且只将该对象传递给 Model .

目前，我遵循选项 A，但我认为它是错误的，所以我正在考虑使用选项 C。

那么，根据 MVC，处理 $_POST 数据的正确方法是什么？

编辑 目前，我没有使用任何 MVC 框架。

EDIT 2 通常，相同的 Controller 处理来自浏览器、网络服务、离线应用程序等的请求，或者每个都有自己的 Controller ?

Answer 1

最好的选择是使用 #2 方法，并进行一些更改。
我会这样写:

public function postLogin( $request )
{
     $service = $this->serviceFactory->build('Recognition');
     $service->authenticate( $request->getParam('username'),
                             $request->getParam('password') );
}
// Yes, that's the whole method

如果您使用类似 Request 实例来抽象用户输入，则无需实际创建变量。

_{Also, you might want to replace theRequest::getParam()method with something likeRequest::getPost()- although I have come to the conclusion that, in a correctly structured application, theGETandPOSTparameters should not share same name.}

您在代码片段中看到的 serviceFactory 将是您在 Controller 和 View 实例中注入(inject)的对象。它可以让您在 Controller 和 View 之间共享相同的服务实例。

它负责创建services (将包含应用程序逻辑，而将域业务逻辑留在 domain objects 中)，这有助于您将域实体和存储抽象之间的交互与表示层隔离开来。

关于其他选项:

• The Controller only calls the Model and the Model handle the $_POST data.

  在 MVC 和受 MVC 启发的设计模式中，模型应该既不了解用户界面，也不了解整个表示层。 PHP 中的 $_POST 变量是 superglobal .

  如果您将它与模型层一起使用，您的代码将绑定(bind)到 Web 界面，甚至是特定的请求方法。

• The Controller transforms $_POST data into a Model's object and only pass the object to Model

  不完全确定您的意思。似乎您在谈论抽象的实例化，它将包含用户的请求。但在这种情况下， Controller 将负责所述结构的实例化/创建，这将违反 SRP .

结束语:

您必须了解的一点是，在基于 Web 的 MVC 应用程序的上下文中，您的应用程序的 User 是浏览器。不是你。浏览器发送请求，请求由路由机制处理，由 Controller 传播。并且 View 产生响应到您的浏览器。

另一件事是:模型既不是类也不是对象。 Model is a layer .

---

更新

Generally, the same Controller handles request from a browser, a web service, an offline application, etc, or each one has it own Controller?

您应该能够拥有处理所有形式的应用程序的单个 Controller 。但这只是在条件下，您实际上对所有 3 个用例都使用相同的应用程序。

要做到这一点有两个条件:

• 您需要抽象 Controller 接收的 Request 实例
• 应在 Controller 外部实例化 View

这样您就可以拥有一个应用程序来满足所有要求。唯一不同的是，每个变体都有不同的是引导阶段，您可以在其中创建 Request 实例并选择正确的 View 。

在您所描述的情况下，更改部分实际上是 View ，因为预计 REST 或 SOAP 服务会产生与普通 Web 应用程序不同的响应。