Ajax時代のMVCモデル

Webアプリケーションの開発では、MVCモデルというソフトウェアパターンが使われている。アプリケーションを本質的なデータであるModel、それを表示するView、それらの制御をつかさどるControllerに分けて作成する方式である。
MVCモデルには思い出がある。もともとMVCはSmalltalk-80で使われたモデルだ。このモデルに取り組んだのは修論の頃だ。当時のSmalltalkではViewとControllerの区別があいまいというより概念的な意味での区分しかなかった。理論を優先し、実行効率を軽んじていたため、批判がなされた。当時の非力なマシンでは当然の批判だ。その結果、Smalltalkの後継では、ViewとControllerが統合され、MVモデルになってしまった。
しかし、Webアプリケーションでは再度MVCモデルが復活した。マシンの性能が飛躍的に向上したことも大きな違いだが、WebアプリではViewが完全に独立している点も大きい。Javaの代表的なフレームワークStrutsでは、Controllerを１つのサーブレット、Viewを複数のJSPで構築する。さらに、Viewはクライアントにも延長している。このような遠隔アプリの発想はオリジナルのSmalltalkにはなかった。
さらに時代は変わり、今やAjaxアプリの時代である。Ajaxアプリは2階層への回帰ではなく、3階層の進化である。Ajax時代には、再度MVCモデルを変更する必要がある。
Ajaxアプリでは、サーバ側はクライアントから呼び出されるAPIおよびデータの集合となる。理想的なAjaxアプリでは、プログラムはほぼ完全にクライアント側に移行する。すなわち、Controllerの主要な部分はクライアントに移る。クライアント側のControllerはイベントハンドラを中心としたJavaScriptプログラムになる。しかし、サーバ側にもアプリケーションとモジュール、メソッドを区別するアクションサーブレットは残る。したがって、Controllerはクライアントとサーバの両方に偏在する。
主なModelはサーバ側に存在する。これは誤解され易い考えかもしれない。一貫性を維持するにはデータはサーバ側になければならない。ゆえに、サーバ側のデータを主とする。一方で、普段はクライアント側のデータを処理する。クライアント側のデータはサーバデータの複製もしくはキャッシュである。よって、従のデータと言える。本質的にはクライアント側にデータはなくてもよい。ただし、効率を考えると、余計な通信を抑制するためにキャッシュとしてクライアントにデータを持つ方がよい。しかし、常にサーバのメインデータを更新する必要もある。
Viewは完全にクライアント側に移行する。APIを介してModelをアクセスする。その意味ではキャッシュとしてのモデルはViewの一部ともいえる。そう解釈すればModelはサーバ側にしかないという言い方もできる。しかし、前述のAPIはWebサービスのAPIを意味した。しかし、実際にはJavaScriptのAPIが提供され、キャッシュされたモデルとViewを密結合するだろう。この場合、Viewは完全にModelから独立する。