前回はプレゼンテーションレイヤの設計と配布について解説しました。今回はこれを踏まえて、Windows FormベースおよびWeb Formベースそれぞれのユーザインターフェイスコンポーネントの設計について説明していきます。

ユーザインターフェイスコンポーネントとユーザインターフェイスプロセスコンポーネント

まず、プレゼンテーションレイヤを構成する「ユーザインターフェイスコンポーネント」と「ユーザインターフェイスプロセスコンポーネント」について、簡単に説明しましょう。

ユーザインターフェイスコンポーネント

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

ユーザインターフェイスプロセスコンポーネント

ユーザインターフェイスコンポーネントから呼び出され、ユーザインターフェイスコンポーネントの要素の表示をコントロールします。また、アプリケーション内で使用する文字コードの統一、ビジネスレイヤの呼び出し、データ受け渡しやエラー処理などを行います。

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

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

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

状態の表示

業務の要件によっても異なりますが、Windows Formアプリケーションはサーバ等に接続された状態だけでなく、出張中などでサーバに接続できない環境での使用も想定されます。そのため、現在の使用環境を操作者に明確に判断できるように設計したほうがよいでしょう。

データの同期

同時に開かれた複数のWindows Form間でデータのやり取りをする場合は、データ連結もしくはWindows Communication Foundation（以降WCFと略します）を用いて同期します。これによりデータの同期のためのコードを大幅に省略することができます。

エラー対応

Windows Form内でもエラーハンドラを実装し、.NET Frameworkが表示する例外画面およびメッセージボックスを表示しないようにします。これらの例外画面内に表示される情報をフォーム内のロジックでキャッチし、操作者に操作の続行を判断させたり、イベントログやアプリケーションログに出力し、障害情報の収集、原因究明のための情報を蓄積するのに役立てるようにします。私がこれまで参加した複数のプロジェクトで得た経験として、正常ケースよりエラーとなるケースのほうが数～数十倍多くなることが多いです。これらのエラーケースにいかに適切に対応できるかによってエンドユーザにとってアプリケーションの信頼性が上がるといっても過言ではないでしょう。

ユーザ操作

ユーザインターフェイスコンポーネントでは、ユーザへのデータのフォーマットの変更、操作の補助、入力値の制限、検証やエラー表示を行います。

データのフォーマットでは、金額の表示項目では通貨記号や桁区切りの挿入、日付項目では「年、月、日」や「/」の自動挿入などがあります。しかし、表示だけではなく、値の入力時には桁区切りや「/」は入力させず、入力確定時に自動挿入させる場合もあります。

ユーザ操作の補助では、マウスやキーボードでの操作やタブキー、カーソルキーなどによる項目の移動や入力、選択項目にあった項目の表示、入力範囲の制限などを行い、業務の流れにあった操作を促し、操作しやすくします。

入力値の制限の一般的な一例としては、日付の入力項目では「昭和」を年号として選択した場合、年の入力値として「1⁠」⁠～「⁠64」の間しか入力できないようにします。これ以外の値（たとえば「70」など）をほかの項目などからコピー・ペーストで入力した場合も入力値の検証でエラーとします。

ユーザ入力制限・補助でよく使用されるのが、DropDownListやListBoxです。しかし、これらの選択項目に対する配慮が欠けている場合があります。たとえば、西暦の選択や日付の選択において、DropDownListではデフォルトでPageUp、PageDownでは28文字送られます。この場合、日付入力で「1日」が表示されている状態でPageDownボタンを押下すると「29日」が表示されていしいます。そこで、移動数を10ずつに変更すると「13日」や「22日」が選択しやすくなります。わずかなことですが、ユーザにとってはキー操作の回数が減るため、操作効率の向上につながります。

必須入力、選択項目については、アプリケーションのポリシーを作成しアプリケーション内で統一したほうがよいでしょう。ただし、必須項目のポリシーをきつくしてしまうと操作性が落ち、操作者の生産性の低下や不満が多くなることがあります。これらは外部設計時に実際の操作者に意見を聞き、同意を得るなどの方法も検討するようにします。

入力値の検証では、上記例のほかに入力または表示された項目間での値の妥当性チェックや、不正な操作を引き起こすSQLインジェクションなどを防ぐ必要があります。一般にSQLインジェクションなどの攻撃は、Webアプリケーションに起こるものと考えられがちですが、Windowsアプリケーションでも発生する可能性があるため、防御する必要があります。

エラー表示については、システムエラー、アプリケーションエラーや、入力・選択項目に関するエラーなどが考えられます。それぞれのエラーの深刻度によってエラー表示の方法が異なってきます。また、入力・選択項目のエラーでは、一画面内で複数個所エラーがある場合のエラー表示方法もポリシーを立て、アプリケーション内で統一したほうがよいでしょう。いずれにしてもいきなりアプリケーションが無反応になる状態やアプリケーションが閉じるなどの現象になることはないように設計する必要があります。

コントロールの作成

アプリケーション固有のコントロールやコントロール群を纏めたカスタムコントロールを作成する場合は、必要となるプロパティ、イベントハンドラ、メソッドのみを公開するようにします。これにより、カスタムコントロールのオブジェクトとしての強度が上がり、汎用性、再利用性、保守性が向上します。また、カスタムコントロールの設計時に、汎用性を高めるためにさまざまなコントロールや機能を追加したくなりますが、結果的にロジックが複雑になったり、再利用性が落ちたりすることが多くなります。カスタムコントロールはできるだけシンプルな構造で設計するようにします[1]⁠。

データベース接続

Windows Form上でComboBoxのListBox等に設定する値をデータベースなどから取得する場合のみ、Windows Formから直接データレイヤのデータベースに接続を許すようにします。これ以外の場合はビジネスレイヤを経由するようにします。ここで、Windows Form上の個別のコントロールから直接データベースに値を取得する方式を採用した場合、複数のクライアントPCからデータベースへの接続回数、同時接続数が増え、データベースへの負荷が増えることとなります。また、SQLインジェクションなどのデータベースへの攻撃の脅威が増えることとなります。これらを踏まえてプレゼンテーションレイヤからデータレイヤに直接接続する場合はよく検討してから設計する必要があります。

作業中のデータ

Windows Formで入力途中の業務データは、それぞれのクライアントPC内で保持するように設計する必要がある場合があります。業務によっては一回の入力では完了せずに複数回、複数日かかることもあります。これらの業務データはどこかに保持しておかなければなりません。そのため、クライアントPC内にデータを保持する方式を検討します。

ここで、1つのシナリオを考えてみましょう。旅行代理店の店舗向けアプリケーションで、ある旅行商品の見積もり業務で複数の交通機関を使用する旅行商品があるとしましょう。この場合、それぞれの交通機関に対してオンラインもしくは電話などで予約をすることになります。一般的に、それぞれの交通機関向けに予約画面が作成されると思われます。店舗係員は予約受付業務で複数の業務画面にわたり操作を行い、最終的にすべての予約が確保されたか確認します。しかし、1つの交通機関だけ予約が確保できないため、全旅程が成立できなかったとします。

それぞれの画面で入力されたデータをデータベースに登録していた場合、すべてのデータを削除しなければなりません。また、上記のシナリオでクライアントPCが停電などでシャットダウンし、再起動が必要になった場合、データベースに残ったデータは誰も消すことはできません。このようなデータを残さないためにも入力途中の業務データはクライアントPC内で保持するように設計します。また、上記のようにクライアントPCで障害が発生した場合、クライアントPCに残った業務データはPCの起動時や業務開始の初期処理で削除するように設計します。

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

③ Officeやスマートクライアントのユーザインターフェイスコンポーネントの設計について

Officeやスマートクライアントのユーザンターフェイスコンポーネントの設計では、以下の点に注意して設計します。

全般

Microsoft社のOffice製品は、以前からCOM+などの技術を用いればVisual BasicやVisual C++で作成したコンポーネントを呼び出し連携することができました。しかし、これらのコンポーネントの作成、配布、管理が大変でした。しかし、Microsoft Office 2003や2007 Microsoft Office systemでは、.NET Frameworkで作成したモジュールやサービス、Webサービスを呼び出すことができます。このため、使い慣れたOffice製品をWindows Formの代わりに使用することが比較的簡単にできるようになりました。しかし、この場合にもWindows Formと同じような注意が必要です。

実は最近、Excel 2007をフロントエンドに用いるアプリケーションが多くなってきています。この場合、WebサービスをExcelから呼び出しデータを取得・加工したのち、Webサービスを経由してデータを登録といった方式のアプリケーションを構築します。この際、途中にWebサービスが入るため、Webサービス側でデータの型変換および検証が必要になります。また、Webサービスの呼び出しには呼び出しのオーバーヘッドがかかるため、レスポンスは悪くなります。また、Webサービスは非接続型であるため、登録後にデータの確認する仕組みを組み込みます。

操作系

スマートクライアントのユーザンターフェイスコンポーネントでは、.NET Compact Frameworkを用いて接続型および非接続型のアプリケーションを構築できます。この場合、Windows Formベースと同様にエラーハンドラを実装し、エラーの有無を操作者に判断させる仕組みを設計する必要があります。また、ユーザの表示領域が小さいため、画面に埋め込むコントロール数を最小限とし、レスポンス・操作性に注意した設計が必要です。また、ユーザ操作補助として、入力回数を減らすため、ユーザ情報をサーバ内に格納し、ユーザ認証を経たのちに表示・確認を促すように画面を設計します。

④ Windows FormベースおよびWeb Formベースに共通するユーザインターフェイスコンポーネントの設計について

Windwos FormベースおよびWeb Formベースに共通するユーザインターフェイスコンポーネントの設計として、以下の点に注意して設計します。

国際化対応

使用されるクライアントPC およびサーバの環境に依存されるのが、国際化対応です。 クライアントPCで使用される言語および通貨、時刻、時差、日付表示、休日などにより、それぞれに対応する必要があります[2]⁠。

Windows FormベースアプリケーションでWPFを使用する場合、1画面に配置したコンテナごとにエンコードを変更することができます。これにより簡易的な言語変換や通貨変換アプリケーションの作成が可能になっています。

Web Formベースアプリケーションでは、日本で構築されるアプリケーションの場合、サーバOSは日本語OSが使用される場合が多いと思われます。しかし、クライアントPC上のブラウザではエンコード設定により表示される言語が変更されてしまいます。そのため、基本的にはUTF-8での使用を推奨し、HTTPヘッダやHTMLで使用言語を規定することが一般的です。多言語利用が想定される場合はそれぞれの画面およびカスタムユーザコントロールを作成することも検討してください。

いずれの場合でもビジネスレイヤやデータレイヤで使用される文字コードは統一し、混乱がないように設計する必要があります。

JIS X 2013:2004

また、Windows Vista以降で使用されているJIS X 0213:2004（JIS2004）による文字の変更については特に注意が必要です。使用されるクライアントPCのOSがWindows Vista以前と混在する場合、Windows Vistaで登録された文字が表示されないなどの現象が発生する可能性があります。また、データベースなどでも不正な文字列としてエラーが発生することが懸念されます。これらはアプリケーション全体のポリシーを作成し、統一する必要があります[3]⁠。

ユーザインターフェイスプロセスコンポーネントの設計について

① ユーザインターフェイスプロセスコンポーネントの設計について

ユーザンターフェイスプロセスコンポーネントの設計では、以下の点に注意して設計します。

概要

ユーザインターフェイスプロセスコンポーネントは、ユーザインターフェイスコンポーネントから呼び出し可能なメソッドを公開するクラスとして公開されます。このクラスは、ユーザインターフェイスコンポーネントからインスタスが生成され、プロセス全体はこのインスタンスを使用します。このインスタンス内で実行されるプロセスから呼び出されるWindows FormやASP.NETのページを動的に構成する場合は、構成ファイルなどのメタデータストアから取得し画面を作成します。

ユーザインターフェイスプロセスコンポーネントとユーザインターフェイスコンポーネントを分離することにより、Web Formなどの非同期アプリケーションやWindows Form、Office製品をフロントエンドとして用いたアプリケーションでの表示・入力の時間に関係なく、業務を続行することができます。

文字コード変換

ユーザインターフェイスプロセスコンポーネントはユーザインターフェイスコンポーネントの要素の表示をコントロールします。その一環として、文字コードの統一のため、複数言語を使用する場合、ユーザインターフェイスプロセスコンポーネントでサポートする言語の文字コードとアプリケーションおよびデータベース内で使用する文字コードへの変換を行います。ここで文字コード変換を行わないと、各言語の文字コード別にビジネスレイヤ内のロジックを作成する必要があり、各レイヤ間の独立性が損なわれることとなります。

しかし、Web Formベースアプリケーションの場合、ユーザンターフェイスプロセスコンポーネントでは文字コードの変換ができないため、ビジネスレイヤのサービスインターフェイスでの変換が必要になります。

各コンポーネントのコントロール

ユーザインターフェイスプロセスコンポーネントは複数のユーザインターフェイスコンポーネント間のデータのやり取り、連携をコントロールします。これにより、複雑なアプリケーションを構築することができます。

ここで、一つのシナリオを考えてみましょう。A社はインターネットサイトで注文を受け付けるサイトを構築します。注文者であるエンドユーザはインターネット経由で注文をしてきます。しかし、クレジットなどの個人情報や配送に関することは個別にオペレータと直接電話でやり取りする場合を想定します。この場合、注文者は注文状況をインターネット経由でブラウザを用いて確認します。A社の電話オペレータは自社内のLAN環境でWindows Formを用いて注文者の注文状況を確認します。この際、ユーザインターフェイスプロセスコンポーネントとユーザインターフェイスコンポーネントが分離されていれば、ユーザインターフェイスプロセスコンポーネントを再利用してWeb Form用とWindows Form用を共通して構築することができます。

ただし、すべてが共通化できるわけでなく、当然、Windows Form個別のロジックやWeb Form個別のロジックは別々に設計・実装する必要があります。しかし、ビジネスレイヤとの通信や画面内の項目間チェックなどの裏側のロジックは共通化ができるため、工数の削減、再利用性の向上、品質の確保が図ることができます。

状態の管理

また、ユーザインターフェイスプロセスコンポーネントの状態を管理・保存する仕組みを検討する必要があります。

Windows FormベースアプリケーションであればローカルPC内や複数のユーザで業務の途中の状態を共有する場合は、サーバやデータベースに保存することを検討します。

Web Formベースアプリケーションでは、ユーザのプロセス状態及び業務データはASP.NETのセッションオブジェクトに保持できます。しかし、保持する先については検討が必要です。IISが稼働しているサーバが複数あり、それらで負荷分散を行っている場合、セッションの状態を保持する専用のサーバを構成し保持するか、SQL Serverを業務データベースとは別に構築し、そこに保持するかを選択する必要がります。この際、SQL Serverに保持されたセッションデータは、保持期限が切れた時に自動的に削除され、蓄積されることはありません。これらのセッションの保持についてはweb.configに記述することができるため、開発時はローカルもしくは開発サーバ内で保持させ、本番環境ではセッションサーバもしくはSQL Serverへ変更することは容易にできます。しかし、本稼働前の負荷テストは本番環境で実施し、検証する必要があります。

例外対応

ユーザンターフェイスプロセスコンポーネントでも例外設計は必要です。この場合、例外を漏れなくキャッチし、メッセージ化し、ログ出力し、ユーザンターフェイスコンポーネントでエラーとして表示させるためのデータを渡します。ここで、エラーオブジェクトを渡してしまうと発生場所の特定が難しくなるばかりでなく、ユーザンターフェイスコンポーネントとの独立性が保てなくなる可能性があります。

トランザクション

トランザクションはプレゼンテーションレイヤから開始・参加や投票しないようにします。これは、プレゼンテーションレイヤは接続型・非接続型の両方があり、設計の統一性を考慮するとトランザクションルートとならないほうがよいことが多いためです。特にデータ更新・削除に伴う業務を設計する場合のトランザクションは排他制御が難しくなります。これらトランザクションはビジネスレイヤで制御し、楽観排他・悲観排他や整合性を保ったデータの参照などを考慮した設計をする必要があります。

レイヤ間の通信

最後にビジネスレイヤとユーザインタフェイスプロセスコンポーネントとの通信についてですが、以前はインプロセス、関数による呼び出し、.NET Remotingなどがありましたが、.NET Framework 3.0以降をフレームワークとして採用する場合はWCFの活用を是非検討してください。今まで煩雑であったデータの受け取りや手順などがWCFを用いることにより非常に簡単に、安全にできるようになっています。生産性の向上、保守性の確保、品質の向上の観点からもWCFの採用を検討してみてください。