n階層システム設計の考慮点

第3回 各コンポーネントの設計について(1)

この記事を読むのに必要な時間:およそ 4 分

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

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

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

表1 ClickOnceとWindowsインストーラの比較表

機能 ClickOnce Windowsインストーラ
自動更新 1
インストール後のロールバック 2 ×
Webからの更新 ×
共有コンポーネントまたはほかのアプリケーションへの影響 ×
付与されるセキュリティアクセス許可 アプリケーションに必要なアクセス許可だけを付与(安全性が高い) 既定でFull Trustを付与(安全性が低い)
必要なセキュリティアクセス許可 インターネットゾーンまたはイントラネットゾーン(CD-ROMからのインストールの場合はFull Trust) Administrator
アプリケーションマニフェストと配置マニフェストの署名 ×
インストール時のユーザーインターフェイス 1つのプロンプト マルチパートのウィザード
必要に応じたアセンブリのインストール ×
共有ファイルのインストール ×
ドライバのインストール × ○(カスタム動作を使用)
グローバルアセンブリキャッシュへのインストール ×
複数ユーザー向けのインストール ×
[スタート]メニューへのアプリケーションの追加
スタートアップグループへのアプリケーションの追加 ×
[お気に入り]メニューへのアプリケーションの追加 ×
ファイルの種類の登録 ×
インストール時のレジストリ アクセス 3 制限
バイナリファイルの修正 ×
アプリケーションのインストール場所 ClickOnceアプリケーションキャッシュ Program Filesフォルダ

  1. Windowsインストーラでは,アプリケーションコードでプログラムによる更新を実装する必要があります。
  2. ClickOnceでは,ロールバックは[プログラムの追加と削除]で使用できます。
  3. ClickOnceの配置でHKEY_LOCAL_MACHINE(HKLM)にアクセスするにはFull Trustアクセス許可が必要です。

(出典:Microsoft社MSDNライブラリ)

これらの制限事項を考慮し,アプリケーションの配布方法を検討した上で設計する必要があります。また,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)などで出力される方法も採用されています。

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

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

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

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

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

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

web.config

Microsoft社製の資料や各種のASP.NETに関する資料・書籍を参照すると,web.configファイルは動的に内容が読み込まれ,反映されると記載されている場合が多いです。しかし,私が以前遭遇したトラブルでは,複数のWebサーバを立て,負荷分散を行っている環境で,一部のWebサーバのみweb.configの内容が反映されない現象が発生しました。

これは,プロセスとしては存在していないのですが,一部のユーザのセッション状態が残っており,これの整合性を保つためにメモリ内に読み込まれたweb.configがリフレシュされない現象が発生したためでした。このとき,手動でweb.configファイルの再配置を行い,web.configの再配置を行った作業者からは対象サーバのweb.configはファイルとしては変更されていることが確認できましたので,サービスの再開をエンドユーザに連絡しました。そのため,このメモリ内に読み込まれたweb.configがリフレッシュされないまま,稼働してしまい,エラーが発生してしまいました。

本現象はIISサービスの再起動およびIIS環境のリセットを行うことで回避できます。本トラブル以降,これらの作業をweb.configの変更を行う際の手順として組み込むことを必須としています。

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

著者プロフィール

露木敏博(つゆきとしひろ)

1966年神奈川県横浜市生まれ。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。

流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。

マイクロソフトMVPアワードプログラムよりDevelopment Platforms - ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。