MVC今昔

ウェブアプリをどう開発するのが正しいか、というのはひとまずおきます。

MVC「モデル・ビュー・コントローラ」って、いまはもう誤解の方が広まりすぎて大元の意味が忘れられているんじゃないかと思いますが、誕生した1979年当時は、語順にしっかり意味があったんですね。

モデルは、コンピュータが生のデータを扱うところ。
ビューは、モデルからもらってきたデータを取捨選択して、人間がわかるように直すところ。
コントローラは、その人間にわかるように直したデータを、今度は出力デバイスが理解できる生のデータに直すところ。

逆もしかりで、

コントローラは、入力デバイスから生のデータをもらうところ。
ビューは、コントローラからもらってきたデータを、人間がわかるように直すところ。
モデルは、ビューからもらったデータを、コンピュータが理解できる生のデータに直して更新するところ。

しかも、ただ機能を分割するだけでなく、ビュー（と、人間）は、生のデータをもらっちゃいけない。かならず（人間が、少なくともビューが理解できるような）加工済みのデータを受け取らないといけない。また、モデルは入出力にまつわるデータを持ってはいけない。ポータブルでなければならない、というのがMVCの根幹をなすルール。

こうしておくと、アプリケーションを別の環境に移植するとき、ハードウェア的な差違はコントローラのみの差し替えで対応できる。CUIからGUIといったユーザインタフェースの変更も、ビュー（とおそらくコントローラ）の差し替えまでで対応できる。逆に、アプリケーション本体を差し替えても、インタフェース部分がかわらない限り、ビューとコントローラは直さなくてすむ。

おおもとの論文は、アラン・ケイのダイナブック構想の枠組みのなかで提出されたものだという背景を前提にすると、もう少し見通しがよくなるかしら。PC-9801があり、FM-7があり、MZがあり、という比較はいまひとつ正しくないかもしれないけれど、いまよりもっとポータビリティが問題になっていた時代の話です。

追記：ポータビリティというのとはちょっと違うか。さまざまな観点からものを見るための道具、ととらえた方がよかった。訂正。

これが、どうしていまのようなMVCになってしまったか、というのはまた長い話になるので省略しますが、この枠組みで考えると、ウェブアプリでもウェブサービスでもなんでもいいけど、ビューやコントローラをはぎとったもの、GUIだろうとCUIだろうとかわらない部分がモデル。ウェブアプリケーションフレームワークとか、あればCUIのフレームワークとかの生データを扱う部分がコントローラ。残りが、どういう名前がついていようと、ビュー。

だから、モデルのなかでどんなマッパを使おうと、インタフェースが一貫しているならかまわない。モデルからビューへ渡す値は特定のマッパのリザルトセットだと規定してしまうなら、それもそれでかまわないけど、そこをオレオレルールとして規定しないでただ「マッパ変えたらビューやコントローラが変わるのは当然でしょ？」と言われると、それはもうMVCじゃないよなあ、とは思う。

もちろん絶対にMVCでつくらないといけないなんてことはないし、実際CatalystはMVCを標榜しているけれどMVC的なつくりにはなっていないのでぶっちゃけどうでもいいわけですが、少なくともいまのCatalystの開発陣、あるいはそれに近い人のなかにはアプリをPARでデプロイできる（単体で完結している）ものだと思っている人がいて、それに対してCatalystアプリなんてもっと大きなアプリ／サービスのひとつのビューでしかないよね、という人、あるいはその中間の人がそれぞれの立場で違和感を感じている、というのが話がいろいろかみあわない原因のひとつだよな、と、そんなことを思った（もちろん私がむだに引っかき回しているというのは自覚しているｗ）。