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 オブジェクトを返す必要があります。

私の目標は、ビュー レイヤーに既に存在するコンテンツ ネゴシエーションを複製しないことです。また、2 つの可能な応答 (JSON と html) があるため、コントローラーがより太くなりますが、それが唯一のケースではない可能性があります。後で XML や別の形式をサポートしたい場合は、それらの応答タイプのすべてのアクション スイッチを用意します。

4

1 に答える 1

2

興味深いことに、現在、コンテンツ ネゴシエーションの側面をビュー戦略リスナーから外し、代わりにコントローラー プラグインに移行することを検討しています。理論的根拠は主にあなたが指摘したとおりです。受信したリクエストを適切なモデルとビューに一致させるのはコントローラーの仕事です。そういうわけで、はい、あなたは正しい方向に進んでいると思います。おそらく、現在 2.1 用に開発されているツールは、あなたが持っている方法論にうまく適合するでしょう。(詳細については、 https://github.com/zendframework/zf2/pull/2615を参照してください。)

于 2012-10-15T13:52:48.310 に答える