一部でMVC議論が流行っていたので、自分のためにSmalltalk由来のMVC(以下、一般化してGUI-MVCと呼びます)はWeb-MVCとどう違うか? という点についてまとめて見ました。突っ込みは歓迎。

あと本稿ではドメインモデル貧血症批判とかは全く盛り込まない。それは少し違うレイヤーの話なんです。

0. VCは大抵の場合、緊密に結びついたペアである GUI-MVCではView-Controller(以下VCペア)は不可分のペアだとされています。情報の入力(および制御)と出力ですから、お互い強く依存するのはあたりまえですね。MicrosoftのMFCとかJavaのSwingではVCはひとつのコンポーネントとして扱っています(Document-Viewパターンとも呼ばれます)

ただ、この点についてはWeb-MVCでもそんなに変わらないかも。

1. GUI-MVCのView-Controllerペアは単位が違う 先ほど述べたようにGUI-MVCのVCペアは、ある種のコンポーネント、画面の部品です。リストデータ(Model)を表示するListView+Controllerとか、表形式のデータを表示するTableView+Controllerとか。WebではMVCは一画面ごとにVCペアを割り当てたりしますが、GUI-MVCではもっと細かい部品の単位でVCペアが存在します。 これはWeb-MVCとはかなり違うところです。Webの世界では「一画面」より小さい画面部品は実質存在しないから同等なのだ! みたいな頓知解答は、この場合不適切ですね。

3. GUI-MVCのVCペアは汎用コンポーネントを目指す Web-MVCではModelの再利用性ばかり宣伝されますが、GUI-MVCではVCペア自体の再利用性も重視されます。コンポーネントなんだから再利用したいですよね。

VCペアを毎回特定のモデル向けに実装するのではなく、VCペアが自分に適合するインタフェースを持つモデルだけ扱うようにします。いちいちVCペアを継承して実装したりせずに再利用可能になります。Smalltalk界隈ではプラガブルMVCと呼ばれるものです。 ただしModel自体の再利用性を高めるという当初の目的には矛盾しそうですね。この問題に対象するためにSmalltalk界隈ではMMVCと呼ばれるMVCの改良版のパターンが考案されました。Modelを、ApplicationModelとDomainModelに分割するという方式です。プラガブルMVCの実現にはMMVCが不可欠というのが俺の理解です。(あってるだろうか?)。 JavaのSwingでも、例えばJTableはTableModelインターフェースを実装したモデルを要求します。開発者は、TableModelを実装したApplicationModelを開発し、それがDomainModelにアクセスするというやり方で対処しています。つまりAdapterパターンですね。

4. GUI-MVCではObserverパターンを利用することが多い これはみんな知ってることだから長々書きませんが、、Modelの変更をViewに反映させるために、Observerパターンを利用することが多いです。また複数のVCペアから構成されるような複雑なコンポーネントが矛盾なくリアルタイムで情報を表示させるためには、ObserverとかMediatorパターンをフル活用する必要があります。(GoF本にそういう例が載ってましたね)