MVCの概念

MVCの概念

プログラミング手法のアプローチの一つとしてMVCと呼ばれるものがあります。
MVCとはModel・View・Controllerの略で、処理を3つの役割に分割して実装する手法です。

Modelは処理のメインロジックやデータアクセスを担当します。
Viewは処理結果として画面表示(HTML出力)を担当します。
そしてControllerはクライアントよりのリクエストを直接受け取って処理を行う、一番前面となる部分で、文字通りModelやViewを「制御」します。

イメージとしてはControllerはリクエスト情報を基にModelに処理を依頼し、
Modelはデータと連携して処理を行い、処理結果をControllerに返し、
Controllerは返ってきた処理結果データをViewに渡し、
Viewはデータを基にHTML出力処理を行う。
という感じになります。
Controllerが最も前面かつ全ての仲介に位置することになります。

PHPも、フレームワークがたくさん出回ってきました。
有力なところで、ZendFramework、CakePHP、Simfonyなどがあります。
これらは全て、便利なライブラリ集であると同時にMVCアーキテクチャを取り入れたリクエスト処理が可能な、MVCフレームワークでもあります。

これらを利用すれば手軽にMVC実装が可能ですが、このコーナーでは敢えてMVCの仕組みを1から作ってみます。そうすることで、MVCとはどんな仕組みで動いているのかを理解する事が出来ると思います。

オブジェクト指向としてのMVC

通常、PHPでオブジェクト指向実装を行うといっても、
実際はURLで指定されたPHPファイルから処理がスタートします。
例えばhttp://www.aiueo.com/aaa.phpというURLでリクエストがあった場合、Webサーバーではドキュメントルート直下のaaa.phpというファイルに処理が入ります。
aaa.phpではクラスファイルの読込を行い、そのクラスのメソッドを使用して処理結果データを生成し、そのデータを基にHTMLを生成してレスポンスとなるHTMLに埋め込むという形を取ります。

当然機能ごとに使用するクラスが異なるので、処理起点となるPHPファイルごとに必要なクラスの呼び出しを行う必要があります。つまり、その処理起点となるphpはクラス化することはできず、また機能ごと処理起点が必要となります。このへんがPHPをオブジェクト指向化する上で中途半端な感じがする一つの要因でもあると思います。

PHPにおけるMVCフレームワークはPHPのオブジェクト指向実装としては究極であると言えると思います。処理を役割分担して、役割ごとにクラスを作る。そして処理起点のPHPを意識することなくクラス実装を行う事が出来ます。

MとVとCそれぞれの役割

モデル(M)・ビュー(V)・コントローラー(C)。
具体的にそれぞれの役割をどのように考えればよいか。

まずコントローラー。
コントローラーのクラス構造はURLに直結するものです。
コントローラークラスとそのメソッドの組み合わせでURLが形成されると考えてください。
そしてリクエスト情報を直接処理するのがコントローラーです。

次にモデルです。
クラス設計の世界ではアプリケーションに関わるオブジェクトをクラスとしてプログラミングに起こすことをモデリングと呼んだりします。
つまりモデルとはアプリケーションに登場する事象をクラス化したものと見ることが出来ます。
つまり、基礎編で説明しているような、オブジェクト指向の基本概念がモデルに当たるわけです。
インターフェイス機能の切り口とモデルの切り口は必ずしも一致しません。
なのでアプリケーションの処理ロジックは全てモデルの役割です。

最後にビューです。
その名の通りWEBアプリにおけるインターフェイス部分に関わる処理を行うのがビューです。つまりHTML生成を担う部分です。
モデルやコントローラーには決してHTML生成ロジックは書かないで、これらによって作り出されたデータをもとにHTML生成を行います。

前述のとおり、コントローラーがモデルとビューを制御します。
コントローラーは絶対に必要です。MVCの中ではURLと直結した処理の基点と言えるからです。
逆に言うとコントローラーに全てのロジックを詰め込んで、コントローラーだけでも動かせるのです。
でもそれは好ましくないと言うか、MVCの意味がありません。
MとVとCが切り離されている事に意味があるのです。
まずモデルは間違いなくアプリケーションの根幹となるビジネスロジックを実装します。
コントローラーはURLと直結すると考えるなら、例えばURLが変更になったとしてもビジネスロジックに影響を与えるべきではありません。また、Webインターフェイスの見栄えに変更があったとしても、これもまたビジネスロジックに影響があるべきではありません。逆に見栄えは変わらないのにデータ構造が変わったとしたら、ビジネスロジックは変更があるけど、それがビューに影響をあたえるべきではありません。そんな感じで切り分ける意味があるわけです。