前回の話で、本来のMVCは、ViewからModelの依存がある、というところで終わった。
この依存がある、というのは、簡単には、ViewのソースコードでModelのメソッドを叩いたりするかどうか、のことだ。Viewから直接Modelに参照するかどうかの話なのだ。他のViewに差し替えても、Modelを叩く作法をViewに教えなければならないのは変わらない。
この依存が気に入らない、という分野があって、それはWebプログラムだったりする。
Webの世界にありがちなMVC
Webプログラムの場合、コントローラー的な要素はHTTP通信によって指定されるURLとMethod（いわゆるGETとPOST）である。そしてGUIアプリケーションとは違い、１度のアクセスで1つの結果を見せるというフロー駆動な性質を持つ。中にはAjaxみたいに刻々と値を変えるものもあるけれど。
こうした性質を踏まえて、RailsやPHPのsmart的な考え方など、Webフレームワークは下図のようになっている。
ViewがModelに依存するのをやめ、ControllerがViewとModelに依存している。つまり、様々なViewの形からControllerが選びとる、という形式になっている。
これはHTTPリクエストが入り口となるControllerを叩き、URLに対応するデータをModelから引き出して持つ。Controllerが持ったデータをViewに差し込む、という手順になる。このような形は、イベント駆動ではなくフロー駆動的であるからこそ、なせるものである。
Webの場合、モデルから引き出した情報をHTMLだけではなく、JSONやXMLに整形したいという要望があったりする。また同じHTMLでも、携帯向けiPhone向けに整形したいということもある。そこで、Controller時点でリクエストされたViewが何であるかを判断（ほとんどの場合は拡張子かユーザーエージェント）し、指定されたView通りの返答を行う。
このときに、Modelがするべき作業をControllerが行ってしまうコードを書きやすい。本当に。そういうコードを書くと、多方面から怒られる。
このとき作られたView、主にHTMLは、モデルとの依存性が低いため、流用が容易である。その代わり、Viewに適したデータ形式に合わせる苦労をControllerが負う。
MCVなアプリケーション
ということで、気分的には、M=C=Vな関係のMVCを、MCVと呼びたくなってくる。その気持ちをぐっと抑えてWeb MVCとかいう言葉の方がいいかもしれない。
このMCVな形を見ていると、Web MVCはWebプログラムの特性、すなわちフロー駆動に合わせたもので、イベント駆動では存在するのか？という疑問が出てくる。このMCVスタイルは、ビューからモデルを直接参照せずにControllerを必ず通すという形になるので、Controllerが整形してViewに渡すという苦労を伴う。
それをうまく解決しているのが、cocoaらしい。Cocoaの本質 MVCデザインパターンを見ると、確かにMCVな形をしている。どうやらCocoaバインディングなるものがViewとModelの橋渡しをするようなのだが、なにぶん、Cocoaは触ったことが無いので分からない。
Mediatorはおやつに入りますか？
実際のところ、MVCがMCVに見えるのは、もともとのMVCのViewが持っていたMediatorという部分が、Controllerに組み入れられたことによるものだ、と感じている。
Mediatorとは何ぞ、というのはPureMVCなどの厳密なMVCの話が関わるので、また次へまわそうと思う。Facadeもあるよ。