このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
Struts 1.x や JSP などの汎用の Servlet 実装を使うと、
Servlet に必要な処理の一部を引き受けてくれるため、
開発者の作業を減らすことができる。
しかしながら、すぐに導入というわけには行かない。
Struts 1.x や JSP はあるパターン（思想）に基づいて
設計されており、その役割は大体決まっている。
なので、これらを利用するためには、処理の流れを整理し、
何をフレームワークに任せ、何を実装しなければならないか、
きちんと整理しておかなければならない。
昨日書いた Servlet の処理を再掲してみよう。
1. アクセスのあった URL が正しいか検証する。
2. 不正なら別の URL に転送するか、HTML 等を出力。
3. URL を元に、どの処理を実行するかどうかを決める。
4. 必要に応じてフォームやパラメータを検証する。
5. 不正なら別の URL に転送するか、HTML 等を出力。
6. 処理を実行する。（最も複雑な部分）
7. 処理の結果に応じて、表示する HTML 等を出力。
これは単に手続をそのまま書いただけなので、
色々な処理が混ざり合って混沌としている。
そのため、役割に着目して整理してみよう。
・表示（ビュー/View）
・手続（プロセス/Process）
・制御（コントロール/Control）
・動作（モデル/Model）
最初に整理すべきは、「表示」と「手続」を分離することだ。
これは、外部設計と内部設計に分ける感じである。
「表示」は利用者のユーザインタフェースであり、
普通のアプリケーションではフォームの設計に当たる部分だ。
Web アプリケーションの場合、画面の表示は、
クライアント上のブラウザで行われるため、
「HTML を生成する処理」であると考えることができる。
上記では、2, 5, 7 で出力する HTML の部分となる。
HTML の生成処理を切り離すことで、
他の部分では、HTML のタグを書いたり、
HTML 固有のエスケープ処理等から解放される。
表示を切り離すメリットはこれだけではない。
簡単に出力形式を切り替えることができるようになる。
例えば、XML のレイアウトを行うモジュールを別に作れば、
他の Web サーバにデータを提供するための
Web サービスを並列で動かすこともできるのである。
さて、表示以外の部分は手続となるのだが、
手続は大きく「制御」と「動作」の 2 つに分かれる。
動作は、実際のアプリケーション固有の処理を行う部分だ。
制御は、どの動作を実行するのかを決定する部分だ。
Web アプリケーションの場合、要求された URL を分析し、
それに対応する処理を行う「動作」インスタンスを作成し、
それを呼び出すのが「制御」の役割となる。
上記では、1, 2, 3 の部分を担当するのが「制御」で、
残った 4, 5, 6 の部分が、「動作」となる。
上記の 6 番は処理の心臓部であるため、
Web アプリケーション開発者が処理コードを書いて、
実装を行うべき部分となる。
上記のように、動作、表示、制御に分離する考え方を、
英語表記である Model, View, Control の頭文字を取って、
MVC アーキテクチャという風に呼ぶのだ。
上記の処理手順を、MVC 風に考え直すとこうなる。
1. アクセスのあった URL を Controller が検証する。
2. 不正なら、エラーに対応する View を呼び出す。
3. URL を元にどの Model を実行するかどうかを決める。
4. Model はフォームやパラメータを検証する。
5. 不正なら Controller にエラー処理を依頼し、
Controller はエラーに対応する View を呼び出す。
6. Model が処理を実行する。
7. 処理結果を View に引き渡す。
8. View が処理結果を元にレイアウトを生成する。
まずは、厳密な定義などはどうでもいいので、
この MVC を感覚的に理解するのが大切なこととなる。