3

在 Zend Framework 2 中，内容协商发生在视图层，我对此非常满意。我的控制器中的一个示例：

public function viewAction()
{
    $id   = $this->params('id');
    $user = $this->getRepository()->findUser();

    return new ViewModel(array(
        'user' => $user,
    ));
}

这要么呈现 view.phtml 模板以返回 html，要么将用户对象转换为 JSON 响应。所谓的视图策略决定了如何根据请求来渲染响应。

我的 webapp 中的“REST”应用程序流程

这种类型的内容协商适用于许多用例：

  1. /user或indexAction()返回用户数组 => 可能的 JSON html；
  2. /user/1或viewAction()返回用户对象 => 可能的 html 或 JSON（上面的示例）；
  3. /user/1/update或updateAction()返回一个 html 表单。出现错误时，此 url 的 POST 将返回 html 或 JSON。或者在成功时它重定向到viewAction()并因此返回用户的新版本 => html 和 JSON 再次可能；
  4. /user/create或createAction()返回一个 html 表单。出现错误时，此 url 的 POST 将返回 html 或 JSON。或者在成功时，它viewAction()可能再次重定向到刚刚创建的用户 => html 和 JSON

我的问题

在一些用例中，内容协商在控制器层中是“必需的”。我不确定我是否忽略了一些可能性：是否有我可以在以下情况下使用的选项？

  1. 删除用户：POST 到/user/1/delete. 如果是 html 视图，您将被重定向到用户列表（现在已删除的用户已丢失）。如果你想要一个 JSON 响应，你想要返回 200 OK 和一个带有删除成功消息的 JSON 对象。
  2. 对博客文章发表评论。如果是 html 视图，您将被重定向到您看到附加评论的帖子。如果您要求 JSON 响应，您希望返回 200 OK 和一个带有您刚刚放置的评论的 JSON 对象。

我的目标是不复制视图层中已经存在的内容协商。这也会使我的控制器更胖，因为我现在有两种可能的响应（JSON 与 html），但这可能不是唯一的情况。如果我以后想要支持 XML 或其他格式，我会为这些响应类型的每个操作切换。

4

1 回答 1

2

有趣的是，我们目前正在考虑将内容协商方面从视图策略侦听器中移出，而是移到控制器插件中。正如您所指出的那样，基本原理很大程度上是-控制器的工作是将传入请求与适当的模型和视图相匹配。因此，是的，我认为你走在正确的轨道上——而且现在正在为 2.1 开发的工具很可能会非常适合你所拥有的方法。（详见https://github.com/zendframework/zf2/pull/2615。）

于 2012-10-15T13:52:48.310 回答