Ajax時代の、サーバ<->クライアントで協調するMVCフレームワーク

最近、WEBサービスのユーザーインターフェースでは、AjaxあるいはAjaxっぽいJavascriptが必須になってきています。つい最近まで、MVCフレームワーク ( Model-view-controller - Wikipedia ) によって、かなり整理が進んでいたWEBアプリケーションのアーキテクチャが、(いい意味で)かなり揺さぶられている雰囲気。

Javascriptで動的に変化するWEBページをつくろうとすると、XHTMLでValidなDom構造であることがすごく重要になります(document.getElementById()とか)。HTMLの構造化を進めていくと、必然的にデザインはCSSに集約されるようになるし、DomとCSSを操作するJavascriptに、コントロール機能が集中するようになる。
こうなってくると、ブラウザ側でも、MVCフレームワークのような概念が定着しつつあるのかな?と何となく思って、以下のような図にまとめてみました。

mvc_client.png

サーバーサイドで、MVCフレームワークが重要になった要因として、WEBアプリケーションの規模に応じて、とてつもなく画面遷移が多くなることがあげられます。画面遷移の制御をコントローラーに集約しないと、手のつけようがなくなってくる。
ただ、実際にWEBアプリケーションをつくって実感するのは、画面遷移の多くは「確認画面」「エラー画面」「設定画面」などの、ユーザーが主に使う画面以外が占めているという事実です。

Ruby on Railsなどの、高速開発を売りにするフレームワークが、Ajaxライブラリと近しい関係にあるのは、単にCoolな見え方を実現するだけでなくて、サーバーサイドの無駄な画面遷移を省略する意味もあるのかなと思います。
今までWEBサーバ上のControllerで行っていた処理の一部を、ブラウザ側のController(Javascript)に移譲する感じでしょうか。

MVCのModelでも、色々なWEBサービスAPIから取得したXMLデータを、JSONオブジェクトとしてブラウザ上に展開するなど、WEBサーバ側で持つ必要がないデータは、直接ブラウザに読み込んでしまう。
またViewでも、CSSでデザインすることを前提に、データ構造をシンプルな<ul>リストからなるDom構造で、自動的に生成するTemplate Engineとか。

なんだかこの半年ぐらいで、WEBプログラミングの環境が、かなり変わってきているような気もします。