今回からは、各コンポーネントの設計についての注意点およびノウハウについて解説していきます。

まずはプレゼンテーションレイヤの設計と配布について解説します。

プレゼンテーションレイヤの設計と配布について

プレゼンテーションレイヤは、ユーザに対して画面や帳票、音などの情報を出力したり、画面やマウスなどの入力デバイスを通して入力・操作をするユーザインターフェイスを提供する2階レイヤです。

.NET Frameworkを使用したアプリケーションはユーザインターフェイスとしては主にWindows FormベースとWeb Formベースが選択可能です。また、これらのほかにもWindows Mobile、スマートデバイス、Office製品をユーザインターフェイスとして選択することも可能です。

ユーザインターフェイスコンポーネントはこれらのユーザインターフェイスを通してユーザとの対話を管理します。これはユーザへのデータやグラフ、図形、サウンドなどを表示・出力し、ユーザからのデータの取得、ユーザインターフェイスの状態の変更、ユーザ操作の流れやタスクの進行の手助けを行います。

前回にも記述しましたが、今日ではさまざまな表現方法が登場しています。特に、.NET Framework 3.0と共にWindows Presentation Framework（以降WPFと略します）が登場し、またその後にはASP.NET AJAX（Asynchronous JavaScript And XML）（⁠※1）が発表されました。

また、新しいものではSilverlightなどがあります。SilverlightとはWebブラウザ上で、オーディオやビデオなどの高品質なメディア配信を行い、ユーザインターフェイスにより豊かな表現力をあたえる.NET ベースのプラグイン技術です。

いずれの技術も、以前はDirectXなどを用いて直接描画していた複雑な画像や、別のウインドウでしか扱えなかった動画などを一つの画面にまとめることができることは非常に素晴らしい技術だと思います。

ところが、一般的な業務画面では「ここまでこった画面を構築する必要がない」とか、「⁠開発工数がかかるので推奨しない」等の言葉をよく耳にします。これらの意見は開発者側の立場での意見で、エンドユーザの意見を考慮したものなのでしょうか?

確かに過度の３Dグラフィックや無駄な動画を画面内に載せる必要はないと思います。しかし、以前私が参加したプロジェクトでは、言葉で表すより3Dグラフィックや動画を駆使して構築したほうがよいアプリケーションもありました[2]⁠。

一般的な操作画面のある業務アプリケーションなどのユーザインターフェイスコンポーネントは、直接最終的なエンドユーザが見て、操作するアプリケーションの入り口です。開発の容易さも必要かとは思いますが、見栄えや使い勝手についても十分に検討が必要だと思います[3]⁠。

また、別の顧客からWebアプリケーションで、画面の一部を選択しただけで画面全体がリフレッシュされるのは画面設計やトラフィックの面からも無駄が多いのではないかと言われたことがあります。確かに、画面の一部の選択状態によって次の選択項目が絞り込まれる場合、さらにその絞り込みの結果がDBからの値を用いる場合などでは常に値が動的に変化します。今ままではポップアップ画面を表示してJavaScriptを経由して値を挿入するなどの方法を用いていましたが、やはり使い勝手はいまひとつです。

このような場合、ASP.NET AJAXを用いれば変更部分だけを入れ替えればよく、複数画面を作ることなくスマートな画面を構築することができます。ただし、この手法では気を付けなくてはいけないことがあります。それは、IISなどのWebサーバのアクセスログの解析が複雑になることです。

一つの画面IDで複数のログが残るので、ツールを用いて解析する必要が出てきています。これらの解析についてサードベンダーからツールが発売されているので、それらを活用することで解決できると思います。

このようにユーザインターフェイスの技術は多岐にわたるため、Windows FormベースとWeb Formベースのそれぞれについての設計時の注意点について解説していきます。

①Windows Formベースのアプリケーションの設計について

Windows Formはよくリッチクライアントと呼ばれます。以前はほかのものに比べて微細な調整ができたり、さまざまな機能を持ったコントロールを扱うことができたりしていたので、このように呼ばれていました。しかし、現在ではWeb Formでもかなり手の込んだ画面を作成できるようになってきています。そのため、Windows Formを選択するかどうかは構築するアプリケーションの特製に合わせて検討する必要があります。

Windows Formを選択したアプリケーションの実行環境は、クライアントPCにアプリケーションをインストールするため、クライアントPCの性能・機能・資産を使用することができます。これにより、業務の流れに沿った操作手順の実現、分かり易いヘルプの表示やグラフィカルな画面、高度なセキュリティ技術を活用したクライアントPC環境の構築などが実現しやすくなります。

Windows Formアプリケーションのネットワーク環境は専用線や社内LAN環境などのセキュア環境での使用が多いと思われます。そのため、たとえば銀行内や証券所でのオンライン業務などの高い秘密性が要求される業務で用いられています。

また、Windows Formベースのアプリケーションでは、オンラインだけでなくオフライン（必要時のみ接続する）での使用も想定されます。

たとえばこのようなシナリオが考えられます。外回りをされている営業の方が社内でネットワークに接続し、必要な業務データを外出用クライアントPCに格納して持ち出し、顧客先などの非接続（オフライン）環境で業務を行うこともあると思われます。その際はクライアントPCからの情報漏洩に注意するだけでなく、オフライン環境で業務を遂行できるようなアプリケーションを構築する必要があります。それはクライアントPC内にオフラインで作成した業務データを保持しておく仕組みを構築することを検討する必要があります。たとえばテキストファイル、XMLファイルもしくは小型のDBを構築する必要があるかもしれません。小型のDBを構築する場合は、維持・管理についての検討が必要となります。いずれも情報漏洩対策を考慮しながら、操作性、運用性のレベルを低下しないようにする必要があります。

また、Windows FormアプリケーションではアプリケーションをクライアントPCにインストールしなければならないため、バージョン管理や配布方法、アプリケーションを実行するユーザ権限などの管理が必要になります。Web Formベースのアプリケーション構築が進んできた背景にはこれらの管理工数の削減を図る意図もあります。

しかし昨今では、ClickOnceによる配置とWindowsインストーラを活用することにより、これらの管理工数を削減することができます。

Windowsインストーラによる配置は、以前から用いられている手法でインストーラを実行し、クライアントPCにアプリケーションを配置（インストール）する手法です。本手法ではアプリケーションで必要となるデバイスドライバのインストール、クライアントPC内の複数のユーザでの使用を可能とすることやレジストリにアプリケーション固有の情報を記述することができます。しかし、インストーラの実行にはAdministrator権限が必要であることなどの制限があります。

一方、ClickOnceによる配置では、Web サイトやネットワーク共有およびCD-ROMなどのメディアから、インストール、更新、および実行できる自己更新型のWindowsアプリケーションとコンソール アプリケーションを配置できます。

しかし、ClickOnceによって配置されたアプリケーションにも下記の「ClickOnceとWindowsインストーラの比較表」に記載されているようなさまざまな制限がかかります。

これらの制限事項を考慮し、アプリケーションの配布方法を検討した上で設計する必要があります。また、Windows Formアプリケーションの配布についてはMicrosoft社のほかにも各社からツールが発売されているので、それらを用いて管理工数を削減することもできます。

②Web Formベースのアプリケーションの設計について

Web FormはクライアントPC動作するブラウザ上で操作するアプリケーションのことを指す場合が多いです。このため、基本的にアプリケーションの配布、インストールなどはありません。Windows Formアプリケーションのようにバージョン管理や配置のための工数を考慮する必要はありません。ただし、クライアントPCにインストールされたOffice製品などと連携する場合は、これらの製品のバージョン管理はしっかり行っておく必要があります。Office製品のバージョン、サービスパックの導入やセキュリティパッチの有無によって動作が変わってしまう場合があります。

Web Formでの基本的な表示方法はブラウザが解釈できるHTML（HyperText Markup Language（ハイパーテキスト・マークアップ・ランゲージ⁠）⁠）で規定されています。しかし昨今は、JavaScriptの技術の向上、Microsoft AJAX Libraryの登場、Adobe ShockwaveやSilverLightsなどの表現が豊かなWeb画面を作成することができるようになってきました。また、Webアプリケーションでの帳票表示では、Adobe ReaderやXPS（XML Paper Specification）などで出力される方法も採用されています。

また、ネットワーク環境においてもSSL（Secure Sockets Layer（エス エス エル⁠）⁠）やVPN（Virtual Private Networkまたは仮想プライベートネットワーク）などによってセキュアな環境での使用ができるようになってきました。

しかし、情報収集、スニッフィング（盗聴）やなりすましといった脅威がすべてなくなったわけではないため、何らかの対策を講じておく必要があります。

Web Formアプリケーションはブラウザ上に表示される画面やデータがすべてサーバから送られてくるため、ネットワーク回線速度がLANと比較して遅い拠点での使用も考慮する必要があります。最近は光ファイバーや高速ADSLなどの普及によって以前のような128kbpsや64kbpsでの接続環境は少なくなってきてはいますが、いまだに外出先での携帯電話を使用した接続環境ではとても遅いことがあります。

このような環境で使用が想定される場合、クライアントPCとサーバ間の通信データの量をできるだけ少なくすることが必要です。

たとえば、ViewStateを使用しないとか、一覧表示を行う際はページングなどを用い、データをサーバ内に保持し、DataGridやGridViewに表示する行数・列数を少なくするなど、通信量をすくなくすることを検討します。

また、画面内のコントロール数を最小必要限とし、たとえば1画面50コントロールまで等の制限を画面設計基準書などに盛り込むことを検討します。加えて、埋め込み型JavaScriptの削減やCascading Style Sheets（以降CSSと略します）の効果的な利用を検討する必要があります。

次回はWindows FormベースおよびWeb Formベースそれぞれのユーザインターフェイスコンポーネントの設計について説明していきます。