COM+ ビジネス ロジック層とプレゼンテーション層の間における対話の最適化
通常、分散アプリケーションの階層間における待ち時間は、大きく異なります。 プレゼンテーション層とビジネス ロジック層の間における呼び出しは、多くの場合、ビジネス層とデータ層の間における呼び出しよりも 1 桁遅くなります。 そのため、ビジネス ロジック層を呼び出すときの方が保留状態にコストがかかります。
次のトピックでは、プレゼンテーション層とビジネス ロジック層の間でデータを渡す方法について説明します。
パラメーターの引き渡し
プレゼンテーション層とビジネス ロジック層の間で渡される情報のセットには、単一行、複数の行、または単一行 (ヘッダーなど) と複数の詳細行の組み合わせがあります。 層の間でこの情報を渡す最も効率的な方法は、単一のメソッド呼び出しです。 この単一の呼び出しでは、渡される情報セット全体が管理されます。 プレゼンテーション層からトランザクションを制御する (およびプレゼンテーション層におけるすべてのトランザクション処理を機能面で同一にする) ことを選択した場合を除き、これは必要なことです。 この層とビジネス ロジック層の間における呼び出しは通常、多層アプリケーションの呼び出しの中で最も低速なため、プレゼンテーション層からトランザクションを実行することはお勧めしません。
このようなメソッドを作成する方法の 1 つとして、情報 1 行をパラメーターとして渡し、複数行を ADO レコードセットとして渡すことができます。 レコードセットは、Microsoft の ADO データ アクセス手法の中核であり、ADO レコードセットを使用すると、1 つのトランザクションに関連するすべての情報を 1 ステップで渡すことができます。
データ受け渡しオプション
データを渡すときに考慮すべき他のオプションがあります。 これには、パラメーターと ADO レコードセットの一覧 (前述のとおり)、ADO レコードセット、XML エンコード文字列、または構造の配列を使用することが含まれます。 このセクションでは、これらの各オプションについて説明します。
次の表は、4 つの異なる引数渡しの可能性のいずれかを使用するとき、特別な注意を払う必要がある領域を示しています。 "X" は、トレードオフについて理解し、各プロジェクトのニーズに照らして検討する必要がある領域を表します。 コンポーネントごとに引数渡しの決定を行わないようにしてください。 プロジェクト全体で一貫したプログラミング モデルを確保することの利点は、最も極端な状況を含むあらゆる状況において、メソッド単位またはコンポーネント単位で最適化する利点をはるかに上回ります。 列については、テーブルの後の一覧で説明します。
| コンカレンシー | WAN | 展開 | 複雑性 | |
|---|---|---|---|---|
| 入力 | Value | |||
| レコードセット |
x |
X |
x |
|
| XML |
x |
X |
x |
|
| 配列 |
x |
X |
x |
4 つの列では、そのオプションを使用してパラメーターを渡すときに注意が必要な領域が定義されます。
- コンカレンシー列は、更新操作のロック条件を管理するメカニズムをコード化または提供する必要性を表します。 保存を実行するメソッドは更新を表すことがあるため、コンカレンシーの問題が発生する可能性があります。 2 種類のロックは、一般的なオプティミスティックとペシミスティックです。 ペシミスティック ロックを使用すると、ユーザーは更新用のデータを取得できなくなりますが、別のユーザーが更新を実行する可能性があります。 オプティミスティック ロックでは、2 人のユーザーが同時に同じドキュメントを更新する可能性に対応することにより、さらに多くのユーザーがサポートされます。 オプティミスティック ロックでは、チェックを呼び出して、保存されているデータが、変更のためにデータのコピーにアクセスがあった時点のデータと一致することを確認します。 ADO レコードセットでは、オプティミスティック ロックが自動的にサポートされます。 単一行のパラメーター リストが関与する更新シナリオでは、コンカレンシー チェックを十分にサポートすることができません。 XML では、XML データにロックの認識が存在しないという点で、この同じ問題が発生します。
- WAN 列は、ワイド エリア ネットワーク (WAN) で伝送の競合が発生する可能性がある条件を表します。 移動されるすべてのデータを一度に管理するための十分な容量が WAN にない場合、アプリケーション ユーザーには応答時間の遅延が発生します。 オプティミスティック コンカレンシーをサポートするため、切断された ADO レコードセットは、サーバーからクライアントにデータの 2 つのコピーを渡します。 2 番目のコピーは、変更がコミットされるときに返される最小の更新行セットを決定するため、クライアントによって使用されます。 これにより、プレゼンテーション層からデータへのトラフィックが削減されますが、2 番目のコピーの追加負荷が大きくなる可能性があります。 したがって、すべての情報を渡す唯一の手段としてレコードセットを使用すると、更新行セットがプレゼンテーション層からデータ層に渡される場合を除き、必要な量の 2 倍のデータが層間で渡されます。
- デプロイ列は、ネットワークの呼び出し元側とコンポーネント側の両方で特別なテクノロジが必要な場合のデータの受け渡しに関連する問題を表します。 たとえば、ADO レコードセットを使用するには、クライアントとサーバーの両方に ADO コンポーネントが存在している必要があります。 アプリケーションにパーサーをコード化する必要がないように、XML パーサーも両方の側に存在している必要があります。
- 複雑さ列は、4 つの選択肢すべてに対して表示されます。開発組織で既に確立されている可能性がある優先または以前のプログラミング モデル エクスペリエンスの問題です。 パラメーターの受け渡しは面倒であり、プログラミングの問題がかなり複雑になると感じる人もいます。 処理しているパラメーターを追跡し、それらすべてを 1 つの編集ウィンドウに表示すると、一部の開発者が管理できないと感じるロジスティクスの複雑さが生じる可能性があります。
パラメーター受け渡しメソッドには、以下のような、トレードオフが存在することがあります。
- パラメーターでは、複数の引数と引数の型を管理する必要があるだけでなく、レコードセットをパラメーターにする適切なタイミングを決定する必要があります。
- ADO レコードセットでは、メソッド パラメーター内の階層リレーションシップを、1 つまたは 2 つの引数に切り捨てることができます。 これにより、プログラミング モデルが大幅に簡略化され、後で列の追加がサポートされますが、情報階層も非表示になります。 ADO レコードセットに情報を詰め込み、後で抽出するには、各列の名前を知っているか、列の順序を知っている必要があります。 この状況により、プロジェクトの他のコンポーネントまたはアプリケーション開発者にとって複雑さが増す可能性があります。
- XML は、上記の非表示階層の複雑さにおける異なるスピンです。 プログラマーは、情報にアクセスするために XML パーサーの使用について理解する必要があり、多くの場合、データ セットが見つかる前に、データ セット内の各項目の名前を知る必要があります。
- 構造の配列では、呼び出し元とコンポーネントの両方の部分で渡される情報に関する共通の理解が必要です。 この 2 つのシステム要素間で共有されているマップが必要な場合、異なるバージョンのコンポーネントを扱う際に問題が発生する可能性があります。 メソッド シグネチャは変更されない可能性がありますが、予想される情報を変更すると、呼び出し元のプログラムに互換性がない可能性があります。
4 つのパラメーター渡しメソッドすべてに関連する複雑さの問題はかなり似ているため、任意の 1 件の選択に関連する大幅な簡略化の機会があることは議論の余地があります。
ファクトリ パターンを使用してデータを渡す
1 つの重要な設計ポイントは、使いやすさです。 ADO レコードセットを使用して構造化された詳細セットをプレゼンテーション層に戻すことを決定した瞬間、複雑な問題が発生しました。 プレゼンテーション層のプログラマーは、これらのレコードセットの構造について理解する必要があります。 レコードセットで一連のデータを渡すために複数の詳細が必要な場合、より複雑な問題が発生する可能性があります。 問題を簡略化するには、構造化された ADO レコードセットでデータを渡す必要があるときは必ず、レコードセット ファクトリ メソッドの作成を検討する必要があります。
レコードセット ファクトリは、書き込み可能な空の切断されたレコードセットを呼び出し元に返す必要があります。 このレコードセットには、呼び出し元のクライアントがレコードセットの作成方法を知る必要がないよう、適切なフィールド (名前とデータ型) が既に構成されている必要があります。 このアプローチは、多くの場合、ファクトリ パターンと呼ばれ、作成の微妙な違いを知らなくても、特定の複雑さのオブジェクトを作成する必要性を解決する一般的なソリューション パターンです。
情報が渡される各メソッドで同じデータに対して同じパラメーター名を選択するなど、単純な設計上の選択により、メソッドを簡単に調べ、何が期待されるかを把握することができます。 like 引数が渡される順序がメソッドのファミリ全体で一貫していることを確認すると、一貫性したモデルが適用される快適なポイントが提供されます。