リッチクライアントとTwo-Step View パターン

いわゆる「リッチクライアント」に分類される、あるプロダクトを調査している。わりと導入事例を耳にするプロダクトで、VBやLotusNotesの経験者にうってつけという印象をもった。プレゼンテーションがこれほどに操作性がよくなれば、大体のユーザーは文句ないと思う。
リッチクライアント＋Webアプリケーションサーバ＋DBというのは、3層Webシステムとしてはかなり理想的な構成だと改めて実感した。MVCのController役をWebブラウザとアプリサーバにまたがらせるしかなく、しかたなくMVC2モデルなんてものをこしらえるしかなかった頃に比べれば、ちゃんとControllerをリッチクライアント側に集約できる。とりわけ良いと思ったのは、アプリケーションサーバとリッチクライアントとの間がかなり疎結合になることだ。どんなにスキルが低く思慮が足りない設計者であっても、疎結合の部分はインタフェース(データフォーマットやオブジェクト構造)をしっかり設計せざるを得なくなる。分散システムだということを強く意識することにつながって、よりよい設計がなされると期待できていいなあ。

WebブラウザのみをクライアントにしたWebアプリを設計するとき、よくTwo-Step Viewパターンの適用を検討する。これは、ビジネスロジック層で使われるオブジェクトを2段階に分けてレンダリングして表示するデザインパターンだ。「ビュー」を論理的画面と物理的画面に分け、オブジェクト→論理的画面(Controller側から見た画面。Name=Valueの集合に付けられた識別子とみなせる)→物理的画面(Presentation 側から見た画面。いわゆるHTML)という順序でレンダリングしていく。リッチクライアントを利用するアプリでは、このパターンの重要度は「使うといいかも」から「使わなきゃやってられない」レベルになっていると思う。