Ajax時代のMVCアーキテクチャについて２

[web2.0][ajax]
前回の続き。
ysano2005 さんが「予想: 2006年のWebアプリケーションのMVCアーキテクチャ」
として書いてある図があるんだが、2段階のリクエストを一緒に描いてる訳だ。

実際のタイミングは2種類あって、最初に URI にリクエストした時の話がこれ。

これが、DefaultView であり初期リクエスト。
Jemplate が埋め込まれた View をサーバーから取得する訳だな。
この時点で、JSON 用意してあってもいいんだが、
今回の例では省略化するためになしにする。

んで、次が Keyup とかで発生する画面描画後の Event だな。
ここが Ajax なところなんだが、それがこんな感じ。

ここでは、サーバーの Model が直接 JSON として帰ってくるから、
サーバー側で View はない。
金子氏 が Model から DataObject に点線引いてるのは、この部分の話だと思う。

んで、このスタイルの問題点を二つほど。
金子氏も言ってるように、

HTMLの構造化を進めていくと、必然的にデザインはCSSに集約されるようになるし、DomとCSSを操作するJavascriptに、コントロール機能が集中するようになる。

まさにこれ。
on compleate (リクエスト完了後のコールバック) を赤い文字にしてるわけだが
MVC モデルとして、Controller が頑張りすぎ。
Controller が View の描画に関わりすぎると、再利用性が薄くなる。
結局、WEBでの MVC モデルをそのまま Client に持ってきただけなんだな。

これは HTTPの仕様上しょうがないところなんだけど、
WEB での MVCモデルってのは、Client での MVC とちょっと違ってて
Model の変更を View に通知する機能が無いってことだ。
だから、Model から処理が帰ってきた Controller が 次のView を呼び出して
その View が Model を参照するようになってる。

もう一つの問題点は、
Client の Controller が直接 Server の Controller 呼び出してるところ。

そりゃ、Google とか Hatena のサーバーなら
ある程度負荷分散考えて作られてるのかもしれんが、
レンタルサーバーとかでこんなアクセスしたら怒られるだろｗ
Hatena の鯖も重いしなぁ。

実際、全部の Event をサーバーに投げなくても Client ですむ話もあるはずで、
例えば、検索後のデータ絞込みとかは Client でやっちゃえばいいし。
他にも直接サーバーに投げるのは弊害がある。
まずレスポンスであり、帰ってきた JSON を利用するプログラムを
コントローラーがやっちゃわないとダメだとか。(Template利用するにしても)

んじゃ、どうするべきなの？
って話だけど、用事があるから次に書こう。

* 関連記事
Ajax時代のMVCアーキテクチャについて

* 参考記事
Jemplate登場によるMVCアーキテクチャ進化の可能性
Ajax時代の、サーバ<->クライアントで協調するMVCフレームワーク