Hatena::ブログ(Diary)

yojikのlog このページをアンテナに追加 RSSフィード

2009-10-19

[tech]GUI-MVCとWeb-MVCの違い

一部で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の世界では「一画面」より小さい画面部品は実質存在しないから同等なのだ! みたいな頓知解答は、この場合不適切ですね。

2. GUI-MVCのVCペアは入れ子になる

TableView+Controllerが、実はTableHeaderView+Controllerと複数のTableRowView+Controllerで構成される*1、といった具合にVCペアが、より複雑なコンポーネントの部品になることがあります。

リストやソースビューアのような単純なコンピーネントから、システムブラウザのような複雑な部品が生まれたりします。つまり分割統治の見本のような形になりますね。(分割統治にはいろいろな切り口があるんです)

ただし入れ子になったVCペアとModelの関係については非常に気になるところです。VCペアが入れ子になった場合、Modelも入れ子になっているのか? それともModelとVCペアの構造は別々なのか。ここは確かに問題になるところでありますが、今回の議論とは別件なので分離します

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本にそういう例が載ってましたね)

結論

と、長々述べましたがWeb-MVCとGUI-MVCは全然違うので、そのパターンが必要となる制約条件や、得られるメリットも全く違うということです。

だからといってWeb-MVCはクソだなーと言うつもりはあまりなく(個人的には好きでは無いですが)、Request-Dispath-Process-Templateパターンとか、そんな名前にすればよかったんだと思います。あんまりキャッチーな名前じゃないから使う人が少なかったかも知れませんが。

*1:これは架空のライブラリを想定しています

artonarton 2009/10/20 02:47 VCがペアというのはちょっと違うのでは。関係はC→V(CはVを良く知っているが、VはCを知っている必要はない)で、かつC(1)……(n)Vです(少なくともGUIでは。Webでもパラメータでjsp切り替えるようなのは1対nと言って良いのでは)。
というのとは別に、JSFとかだとGUIに近いペアになりますね。

yojikyojik 2009/10/20 10:03 VCペアに関してはSmalltalkのイメージが強いかもしれません。。。
JSFって結構コンポーネント指向ですね。
ただHTTP上で動くにはオーバースペックな感じがしますねー
(個人的にはClickみたいなチープな仕組みに惹かれます)

ogijunogijun 2009/10/21 01:17 MVCの歴史はVとCをどれだけ引き剥すかの歴史であるような気がします。ペアに見えた時代はけっこう古いのでは..。
あと、もちろんごyojikさんは存知だと思いますが、1画面より細かい単位でコンポーネント化されて、入れ子になったときにはresponderチェーンがあって、View側からの通知をHTTPリクエストのタイミングに合わせて再定義してobserveさせたり、っていうことを実現していたweb application frameworkもちゃんと存在してたんですよ! ということを強く言っておきたい。

sumimsumim 2009/10/21 08:39 けっきょくGUI-MVCであってもSmalltalkのMVCと他のとでは区別した方がよいのでしょうね。

yojikyojik 2009/10/21 10:46
> ogijunさん
VC依存については、(SwingやMFCのような)いっそ合体させてしまえ!派と可能な限り引き離す派のせめぎあいがありそうですね。
WebFramework業界のオーパーツことWebObjectsですね!! VisualWaveなんかもそんな感じだったのでしょうか(オーパーツすぎてWebで殆ど資料が無い。。)

> sumimさん
そうですね。。Web-MVCがさらにさらに元のMVCから遠い存在になっていく!!

umejavaumejava 2009/10/21 14:25 皆さんがControllerと呼んでいるのはPresenterのことではないでしょうかね。例えば http://aviadezra.blogspot.com/2007/07/twisting-mvp-triad-say-hello-to-mvpc.html 辺りがわかりやすいかと思います。クラシカルなMVCではVCはほとんどの場合ペアと考えて良いと思います。VCはやがてV'として一体化し、Mの一部が分離してPになり、これがCと呼ばれたりするので混乱するという感じでしょうか。

umejavaumejava 2009/10/21 14:34 ちなみに0から3までそのままあてはまってしまうSeasideのようなWeb系のフレームワークもありますね(継続とPostback、もしくはAjaxやCommetで4には対処)。コレジャナイMVCだったWeb-MVCも、最近は技術の進歩により様相が変わってきているのかもしれません。

yojikyojik 2009/10/21 23:15 Seasideは確かにコンポーネント指向ですね。
多言語だとScalaのLiftとかは…どうなんだろう(よくわからない)

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/yojik/20091019/1255963600