{ End Bracket }: リッチアプリケーションとリーチアプリケーション

MSDN マガジン

Microsoft patterns & practices の Composite Application Guidance for WPF で複合アプリケーションを作成する利点を紹介します。

Glenn Block

MSDN Magazine September 2008

...

Chris Tavares は、ASP.NET MVC Framework の Model View Controller パターンが、柔軟性に富み簡単にテストできる Web アプリケーションの作成にどのように役立つかを説明しています。

Chris Tavares

MSDN Magazine March 2008

...

James Avery does it again with his popular list of developer tools. This time he covers the best Visual Studio add-ins available today that you can download for free.

James Avery

MSDN Magazine December 2005

...

サイドバーガジェットは小さいけれど強力なツールで、驚くほど簡単に作成できます。ここでは、Donavon West がその楽しさを教えてくれます。

Donavon West

MSDN Magazine August 2007

...

Paul DiLascia

MSDN Magazine August 2002

...

Read more!

{ End Bracket }

リッチアプリケーションとリーチアプリケーション

Terry Crowley

リッチ (rich) アプリケーションとリーチ (reach) アプリケーションの違いは、これまでのところ明確でした。リッチアプリケーションは本来コンピュータ上で実行され、ローカルグラフィック、CPU、メモリ、およびストレージ機能を利用してきました。リーチアプリケーションは HTML で作成されてブラウザに展開され、システムへの依存を最小限に抑えていました。最近は、この境界線がぼやけてきています。AJAX アプリケーションは大量のコードをダウンロードし、洗練され、応答性の高いアプリケーションを提供できます。Flash、Silverlight™、および Google Gears などのランタイムを使用すれば、ローカルの CPU およびグラフィックス機能やローカルストレージを利用したり、オフラインで実行したりすることのできるアプリケーションを作成できます。

リッチアプリケーション側では、ClickOnce によるマネージアプリケーションの展開機能や、Microsoft® SoftGrid® などのアプリケーションの仮想化およびストリーミング用ツールによって、本来のリッチアプリケーションの面倒な展開が大幅に軽減されました。さらに重要なのは、リモートデータと対話するリッチクライアントの機能を強化し、より洗練されたものにすることです。Microsoft OneNote® がこの良い例です。OneNote は個人用のノートが取れるアプリケーションだと考えられていることが多いですが、サーバーまたはサービス上に保存されたノートブックを共有できる優れた "それだけで動く" 機能が用意されています。リモートデータは透過的にバックグラウンドでキャッシュされ、ネットワーク接続が変化した場合でも、アプリケーションの応答性は常に維持されます。ローカルキャッシュにより、オフラインでのアクセスがサポートされます。変更はシームレスにマージされ、厄介な手動でのオーバーヘッドが生じることなしに、wiki と同様のコラボレーションが実現します。

HTML リーチアプリケーションは、複雑さを "切り離し"、主なビジネスの問題に焦点を置くことで、迅速に展開するというメリットを最初に実現しました。機能が追加されるにつれ、複雑さも増します。AJAX アプリケーションが持つ非同期の本質は応答性の高いユーザーエクスペリエンスに不可欠ですが、複数の未解決の非同期対話およびユーザーエクスペリエンスに対するそれらの影響の状態を管理することが複雑になる場合があります。

チェックしてください

Terry Crowley の "分離コード" インタビューを channel9.msdn.com/Shows/Behind_The_Code でご覧いただけます。

Model View Controller デザインパターンは堅牢なプログラミングモデルを提供する点では優れていますが、サーバーとブラウザに分散された場合に、モデルとビューの間の境界線は拡張されます。ローカルでの応答性とオフライン機能を提供する場合は、モデルのより多くの部分をローカルクライアントに移動することが議論されますが、これによりサーバーとクライアントの境界が複雑になり、この境界を越えて状態および基になるアプリケーションモデルを管理するしくみが複雑になります。クライアントにダウンロードする必要のあるデータの量を最小限に抑えるようにし、その部分モデルをローカルでどのように操作するかを管理することは、本来ストレスの多い作業です。

JavaScript などのスクリプト言語は生産性を大きく向上できますが、リーチアプリケーションで実行されるコードが大量になり複雑さが増えるにつれ、こうした複雑さを管理するために Silverlight での ECMAScript 4 または C# などの "大規模プログラミング" をサポートする言語がますます欠かせなくなってきています。筆者は何万行もの JavaScript コードを書いてアプリケーションを構築してきたチームに多大な尊敬の念を抱いていますが、JavaScript には何十年もの間取り上げられてきた大規模なアプリケーションの構造化に不可欠な言語機能が欠けています。

リーチアプリケーションにオフライン機能を提供することを検討しているとき、ほとんどの人がこれをどれほど軽視しているかということに筆者は驚きました。ローカルにあるキーおよび値のストア、または簡単なデータベースへのアクセスが提供されて、それで終わりました。とんでもないことです。優れたアプリケーションには高度なセマンティックモデルがあります。高度なモデルであるほど、ローカル状態は複雑になり、そのローカル状態をマージしてサーバーに戻す処理 (ユーザーモデルなど) は複雑になります。

リモートデータと対話するリッチアプリケーションについて、筆者はいつも Microsoft の Pat Helland の次の言葉を思い出します。「私たちはアインシュタインの宇宙に住んでいるのですから、同時性などというものは存在しないのです。」2 フェーズコミットなどのデータベース技術は、本来は同時性の錯覚を提供しようとするものですが、応答性と洗練されたスケーラビリティ機能が犠牲になります。

もっと良い方法は、システムの分散コンポーネントは常に "実世界の" 異なるビューを持つものであり、最終的にあまり高度な整合性を求めることはできないことを受け入れることです。これは、システムの分散コンポーネントの基になるモデルの整合性を常に維持するよう骨を折るのではなく (そして、結果として脆弱で応答しないシステムを構築するのではなく)、不整合性を受け入れ、堅牢性を維持しつつこれらの避けられない不整合性をどのように解決するかに尽力する必要があることを意味しています。このような疎結合モデルは多くの場合、最終的に優れたアーキテクチャ戦略となります。宇宙物理学がこの考えの中心基盤をなしていることを認識するのは良いことです。

結局、リーチアプリケーションとリッチアプリケーションの境界や機能の境目がなくなるにつれて、これらのアプリケーションを構築する開発者が直面する問題も収束していくことでしょう。困難な問題を解決している最中には、優れたデザイン戦略のほか、優れたツールも必要です。

Terry Crowley は Microsoft テクニカルフェローであり、Office 開発部門のディレクターです。彼は過去 25 年間にわたり Microsoft、Vermeer、Beyond、および BBN でインターネット対応の高度なアプリケーションを開発してきました。