Web アプリケーションで MVC を考える - リクエストの取り扱い

　View の入力を最初に受け取るのは Controller だ。

　となれば、

「Web アプリケーションにおいて、HTTP リクエスト（以降、リクエスト）は Controller が取り扱う」

　が仮定される。

　これは正しいかを検討してみる。

　リクエストはヘッダとボディで構成されている。ただし Web アプリケーションでは、ヘッダはWeb サーバ（以降サーバ）ないしフレームワーク（以降 F/W）で処理を済ませてしまうことが多いため、今回は考えない。

　残るボディ。Web アプリケーション、CGI の伝統からボディは「キー=値」の組み合わせであるとする。この値の組み合わせによって「リクエストが期待する動作が決定する」、つまり「リクエストに対するHTTP レスポンス（以降、レスポンス）が決定する」とする。

　最終的にレスポンスを作るのは View の仕事だ。全体を通じて見るとレスポンスはリクエストに依存するが、仮定によりリクエストは Controller が取り扱うため、View はリクエストを考慮しない。View にとってリクエストとレスポンスは切り離されていて、依存しない。では View は何を以ってレスポンスを作るべきか。

　MVC ではModel がデータを取り扱う。データには外部から与えられるものと内部に蓄積されているもの（内部データ）の２つが存在する。この外部から与えられるもの（以降、外部データ）が、Web アプリケーションにとってはリクエストに当たる。前述のとおりヘッダは意識しないため、ボディの「キー=値」の組み合わせとなる。

　仮定により View と同様、Model はリクエストを意識しない。つまり外部データは Controller が Model に渡すことになる。Model は Controller から受け取った外部データと内部データを複合的に取り扱うことになる。

　全体を通じて見るとレスポンスはリクエストに依存するため、レスポンスは Model の結果を元に作成されることになる。

　さてView は何を以ってレスポンスを作るべきか。つまり Model の結果を元にレスポンスを作成することになる。MVC では Model から View に直接接続することがないため、Controller が Model の結果を受け取って、View に引き渡すことになる。

　全体の流れを見ると、Controller はリクエストを外部データとして Model に渡し、その結果を View に渡すという構造になる。

　ちぐはぐになってしまった。

　Controller は View の結果を受け取らないし、F/W が Controller の結果を受け取れない。

　つまり仮定の

「Web アプリケーションにおいて、HTTP リクエスト（以降、リクエスト）は Controller が取り扱う」

　は正しくないということになる。

　ではリクエストを取り扱うべきは Controller ではないのか。

　ちぐはぐさを無くすために、下記の図を考えてみる。

　この図から導き出されることは、

「Controller はリクエストから Model と View を選択する」

　ということ。

　Controller はあくまでリクエストを元に Model を選択しているだけだが、リクエストを取り扱っている。そして Model もリクエストを取り扱っている。

　つまり局所的に管理するのではなく、

「リクエストは Controller と Model で取り扱われる」

　ということになる。

　さて、これは正しいのか。