リッチクライアントとMVCモデル

設計

一般にはリッチクライアントはユーザエクペリエンス（ユーザ体験）やユーザビリティの観点で語られることが多いですが、MVCモデルにおけるビューの観点でも無視できないと思います。
リッチクライアントではリッチなユーザエクペリエンスを実現すると同時に、MVCモデルにおけるビューの実行がクライアント側へシフトし、サーバ側はビューで表示するための情報を返すのみといった役割分担が明確になってゆく傾向にあります。
従来のWEBアプリケーションではサーバ側のアプリケーションがHTMLを都度生成するということで実質的にビューの機能の実現がサーバ側にもロジックとして組み込まれていて、この点がビューの分離をあいまいにする要因になっていました。
しかしAjax＋リッチクライアントの流行と共にこのビューの分離とクライアント側による実行の流れが加速してきていると思います。
これはある情報が様々なビューで活用できるような汎用的な設計を行う観点からも情報とその表現（レンダリング）は分離されるべきであり、また情報管理はサーバで管理されるほうが合理的であるという考え方に合致するものだと考えています。
個人的な意見として適切な情報の表現はユーザの都合に依存すると考えるのでユーザ側による自由度が大きいほうが良いと考えています。
また現実的な問題としてサーバのリソースやネットワーク帯域を節約し比較的余裕のあるクライアント側のリソースを活用する合理的な効果もあると思います。


改めて考えるとリッチクライアントの考えや技術はFlash、Javaアプレット、DHTML+JavaScriptなどかなり以前からあったものだと思います。
以前と最近で何が変わったかといえばやはりAjaxの発展によりリッチクライアントとWEB APIに代表される情報の分離だと思います。
ここで今日のリッチクライアントのプラットフォームを考えを整理しておきたいと思います。


１．汎用的で軽量なもの
　　AdobeのAirやMicrosoftのSiliverlightがこの範疇の最新技術だと思います。
　　JavaScriptブラウザの互換性や機能的、開発生産性の課題がありますが
　　ベンダ非依存の要求から一定のシェアは保つと思われます。
２．汎用的で重量なもの
　　JavaアプレットやActiveXなどがこの範疇だと思います。
　　設計の自由度とベンダへの依存や実行環境の配置（インストール）などが
　　課題となります。
３．特定用途向け汎用アプリケーション
　　Microsoft WORDやEXCELなど、一般の汎用アプリケーションをビューとして
　　マクロなどのアプリケーション拡張機能によりWEB APIなどのサーバ呼び出しを行う。
４．個別アプリケーション開発


一般的に注目されるのは上記の１．の技術だと思います。
しかし当面特定の用途に限られるのであればアジャイルな発想で悩まずに生産性の高い方法を選択するのが良いと思います。
悩みに悩んで練りに練って実装しても、ユーザの要望はすぐ変わるのですから。
特に業務アプリケーションでは一般的には盲点である３．の選択肢も検討の価値があると思います。
ユーザ自身が従来から使い慣れているアプリケーションを活用することでユーザ自身によるカスタマイズの可能性もあります。


従来もっとも大きかった問題は、ビューの分離が不十分でちょっとした変更にも修正と確認に大変な工数がかかっていたことだと思います。
重要なのはビューを分離してクライアント側のビューとサーバ側ロジックとそれぞれを独立して修正と確認を可能にし、ビューの取替えを容易な設計とすることで生産性と保守性を向上させることだと思います。
この設計の方針は技術動向やトレンドなどに左右されにくい、中長期的に有効な戦略だと思います。