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

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

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

② Web Formベースのユーザインターフェイスコンポーネントの設計について

Web Formベースのユーザンターフェイスコンポーネントの設計では,以下の点に注意して設計します。

ASPとASP.NET

Web FormベースのアプリケーションはASP.NETを用いて作成します。ASP.NETでは豊富なユーザインターフェイスコントロールが提供されており,Web Fromを用いた画面を比較的簡単に作成することができます。また,HTML準拠の画面のソースファイルとサーバで稼働するInternet Information Server(以降IISと略します)の上で実行されるロジック部分のソースファイルを分離することができるため,画面のデザイナーは画面開発に専任させることができます。また,ロジック部分が分離できるため,従来のActive Server Page(以降ASPと略します)よりもセキュアなアプリケーションを構築することができます。ASP.NETでもASPのように画面部分にもロジックを記述するすことは可能です。しかし,あまり推奨はできません。

ASP.NETではIIS上での動作の変更により,ASPからの移植がとても難しくなりました。ASPで使用されていたHTMLコントロールはASP.NETにそのまま移植しても同じような動作をすることができず,ほとんどのASP の画面はエラーとなりそのままでは動作しない場合が多いです。そのため,ASPで作成されたアプリケーションはASP.NETでは新規に構築したほうが,工数・手間を考えるとよい場合が多いようです。

サーバ・クライアント環境

Webアプリケーションなので,IISと接続した状態で稼働します。そのため,動作環境および処理能力はIISが稼働しているサーバの性能に依存します。また,クライアントPC上のブラウザの環境にも依存する部分が多くなります。

たとえば,ブラウザの種類・バージョンにより,HTMLやCSSの解釈の違いにより表示が異なったり,ブラウザのオプションによりJavaScriptが無効になっていることで,ブラウザ内での表示・動作が異なったり,値のチェックができないなどの現象が発生します。このようにWindows Formベースのアプリケーションより環境に影響されやすくなります。

Web Formアプリケーションでは,アプリケーションの配布やアプリケーションのインストールの必要がないなどの管理面での利点がある一方,クライアントPCの環境,ブラウザの設定などを統一させる必要があります。これらは設計の段階でリスクと管理コストを見積もっておく必要があります。

キャッシュ

ページが要求されるたびに再描画が行われることを避けるために,ユーザインターフェイスユーティリティコンポーネントの出力をキャッシュするように設定できます。これは更新頻度が少なく,再利用される可能性が高いページのみ有効です。

ページング

ページング用のユーティリティコンポーネントを使用します。一覧表示などで大量のデータを表示させる場合,すべてのデータをクライアントPCに送信するのではなく,セッションデータをサーバ内に保持し,一部のデータのみをクライアントPCに送信する方式を用います。これにより,データの通信量を抑えることができます。しかし,100万件などの大量データをサーバ内に保持することは,サーバのメモリもしくはセッションデータを保持するサーバの資源を圧迫することとなるため,対象件数が多い場合などはエラーや警告などを表示し,対象データを少なくするようにすることも検討します。

エラー対応

Web Formベースのユーザインターフェイスコンポーネントでも,エラーに対する設計が必要になります。これはGlobal.aspxにグローバル例外ハンドラを実装し,カスタムエラーのページが表示されるように実装します。これにより,プレゼンテーションレイヤで発生した例外に対しても設計者がコントロールしたエラーページを表示できるようになります。

データのチェック

データの必須チェックやユーザの入力したデータの妥当性チェック(業務要件的ではなく,入力値として妥当であるか)はブラウザ側でもチェックするようにします。これにより,クライアントPCとサーバ間の通信量が削減できるとともに,不正なデータがサーバに送られる可能性をわずかながら減らすことができます。

これに対してサーバ側では,入力値の妥当性チェックのほかに,SQLインジェクションなどの不正な文字が混在していないかなどのチェック,業務ロジック的なチェック,項目間の整合性チェックやデータベースへの問い合わせが必要なチェックなどを実施します。

クライアントPC上のブラウザでチェックする機能はJavaScriptで実装されます。しかし,クライアントPCのブラウザ上でJavaScriptが有効になっていない場合,これらのチェックが機能しないことがあります。そのため,サーバ側で実行されるユーザインターフェイスコンポーネントのロジック部に必ずこれらの検証を行う機能を設計します。

画像

入力値の検証についてはWindows Formベースのユーザインターフェイスコンポーネントでも説明していますので,そちらをご参照願います。

セキュリティ

Web Formベースのアプリケーションでは,Windows Formベースのアプリケーションよりも多くの脅威が存在します。

たとえば,入力文字列に不正なデータベース操作文字を混入するSQLインジェクション,アプリケーションが想定していない入力内容によりアプリケーションの境界を超えるしまうバッファオーバーフロー,サイト間を横断して悪意のあるスクリプトを混入させるクロスサイトスクリプティング,URLに埋め込まれたパラメータやネットワークの盗聴などによるユーザID・パスワードの不正入手によるなりすまし,以前のセッションで作成されたCoockieを再利用されるCookie リプレイ,ブックマークで記録されたページへの直接アクセス,画面表示データからの個人情報漏洩など,さまざまな脅威が存在します。ここではそれぞれの脅威に対する対策について詳細な説明は省きますが,設計時にこれらの対策について検討する必要があります。

クライアントでのデータ整形

Web Formベースのユーザインターフェイスコンポーネントでも入力データのフォーマットなどは行うことができます。しかし,これらはJavaScriptで実装されることになるため,過度の使用は制限するようにします。これらの機能を実装したjsファイルをWebアプリケーション接続時にダウンロードし,各画面で共通的に使用することはできますが,初期起動画面のレスポンスの低下や保守性が低下することがあります。

カスタムコントロール

Web Formベースのユーザインターフェイスコンポーネントでも,アプリケーション固有のコントロールやコントロール群を纏めたカスタムコントロールを作成する場合は,必要となるプロパティ,イベントハンドラ,メソッドのみを公開するようにします。

著者プロフィール

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

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

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

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