Ajax環境に置けるMVC考察

Posted by dab | 2012年9月4日 火曜日 22:06:23 < JavaScript, コンピュータ >

WebアプリにおけるMVC考察。


(Ajaxではない)CGIアプリでは、Viewの部分がHTMLを出力するだけで、描画そのものはブラウザが全部やってくれていた。
ModelがHTMLを生成していると、ブラウザがViewといっても良いかもしれない。


しかしAjax環境では、XMLHttpRequest(以後XHR)による通信が必要になるため、CGIアプリがHTMLを出力したら終わりというわけではなく、受信したHTMLデータをブラウザに渡す処理(JavaScript)が必要になる。

Viewの一部をXHRに置き換えたものが、フレームワークとして数多く発表されている。
サーバーサイドのViewでHTMLにしておくと、クライアントサイドでは受け取ったraw dataをそのままブラウザに渡し、innerHTMLに代入するだけで描画が終わる。
そのためViewの受信部分は以下のような1行で終わってしまう事が多い。

output.innerHTML=xhr http://viagraindi....responseText;

サーバーサイド、クライアントサイドでそれぞれMVCモデルを採用したものが以下。

まずサーバーサイドは先のCGIアプリと同じ。
出力がHTMLではなく、JSON/XMLに変わっただけである。

次にクライアントサイド。
JSONやXMLでデータを受け取るため、それをHTMLに変換し、ブラウザに渡す部分がViewとなる。
Controllerはイベントハンドラからサーバーに送信するデータを生成したり、データベースとHTMLへの変換処理の中継を行う。
Modelはサーバーとの通信しか行わないため、実質、XHR本体だけとなるが、データ生成を担当する事もある。その場合は、Controllerの処理が省略される。

このタイプのメリットは、Modelがサーバーに通信するだけでなく、localstorageやcookieと、サーバーデータとの比較が、クライアントサイドで可能だと言う事である。
localstorageにデータが保存されていれば、わざわざサーバーに通信する事無くlocalstorageからデータを取り出し、Viewに渡す事で描画まで完了する。
localstorageにデータが保存されていなければ、サーバーと通信してデータを受け取り、localstorageに保存した上でViewにデータを渡す。
次に同じデータが必要になった時は、localstorageから取り出せば良い。

サーバーサイドでも同様のキャッシュ機能を実現できる。
Controllerがまず、Viewに問い合わせる。
Viewはキャッシュファイルに生成済みJSON/XMLデータがあればそのデータを返す。なければModel-Viewを使って生成する。
とはいえこのサーバーサイドのキャッシング方法は他のMVCモデルでも作る事は可能であるし、クライアントがキャッシュしているので、サーバーでキャッシュする必要性は少ないと思われる。

もちろんクライアントサイドでもViewが生成済みHTMLをキャッシュする事は可能だが、localstorageは無限ではないし、少しでもデータ量を減らしたいのが実情。
そのため、Modelがraw dataを保存しておき、localstorageから取り出すかサーバーに問い合わせるかを判断する方が現実的ではないかと思う。

また、この仕組みのフレームワークであれば、クライアントサイドだけを使えばサーバーとの通信が発生しない(ウェブアプリやクライアント-サーバー型ではない)スタンドアロンアプリや、オフライン対応のウェブアプリも作る事も出来る。
さらにサーバーサイドとクライアントサイドが分離している事から、サーバーサイドをPerlからPHP、Javaなどの言語に変更したり、Perl用フレームワークだけ、PHP用フレームワークだけを変更、個別に選ぶ事も可能である。


参考サイト
Google Groups HTML5.jp | 中小規模Webアプリケーションの製作におけるMVCについて

TrackBack URI : http://home.wi-wi.jp/blog/wp-trackback.php?p=1146

Leave a comment

:mrgreen: :neutral: :twisted: :shock: :smile: :???: :cool: :evil: :grin: :oops: :razz: :roll: :wink: :cry: :eek: :lol: :mad: :sad: