この付録の内容は次のとおりです。
PeopleToolsを使用したソリューションの開発経験者は、PeopleToolsコンポーネントの構造をよく理解しています。ADFビジネス・コンポーネントには、PeopleToolsで使い慣れているデータ・アクセス機能が実装されています。
表A-1 PeopleTools開発者が理解しやすい概念
概念 | Oracle ADFへのマッピング | 類似点 |
---|---|---|
ヘッドレス・コンポーネント |
アプリケーション・モジュール |
Oracle ADFはMVCパターンに従い、ビューからモデルを分離します。PeopleToolsコンポーネントで使い慣れているページは、WebベースのアプリケーションのためのJSFコンポーネントやADF Facesコンポーネント、またはデスクトップ・フィデリティ・クライアント表示のためのSwingなどの標準テクノロジを使用し、ビュー・レイヤーで定義されます。 ADFアプリケーション・モジュールは、PeopleToolsコンポーネント・バッファと同様にデータ構造を定義します。データの行セットを生成するADF問合せコンポーネントとの間にマスター/ディテール関係を定義することにより、データと連携するすべてのアプリケーション・モジュールは、必要に応じて、コンポーネント・バッファのスクロール・レベルに類似した自然な階層を再使用できます。 使い慣れたコンポーネント・インタフェースと同様に、アプリケーション・モジュールは、標準メソッドおよび追加的な開発者定義ビジネス・ロジックへのアクセスを提供するサービス・オブジェクトです。特定のユーザー・インタフェースに対して「ヘッドレス」なデータ・サービスを提供するために、コンポーネント・インタフェースでは、UIの対話に関連するPeopleToolsのファンクションの数が制限されます。アプリケーション・モジュールは、「ヘッドレス」なデータ・サービスを提供するという点ではコンポーネント・インタフェースと類似していますが、既存のユーザー・インタフェースの制限されたビューをラップする手法ではデータを提供していません。かわりに、アプリケーション・モジュールはビジネス・ロジックとデータ・アクセスのみを処理するよう設計されています。ADFビジネス・コンポーネントでは、コンポーネント上にコンポーネント・インタフェースを構築するのではなく、まずユーザー・インタフェースとは別のアプリケーション・モジュール・サービスを構築し、次にこのサービス上に1つまたは複数のページを構築して、アプリケーションのエンド・ユーザー・タスクを処理します。 アプリケーション・モジュールは、PeopleToolsコンポーネント・バッファと同じ方法でトランザクション・オブジェクトに関連付けられています。アプリケーション・モジュールは、自身に含まれているコンポーネントに対し、データベース接続を提供します。現在、コンポーネントPeopleCodeとしてトランザクションと関連付けているすべてのロジックは、ADFビジネス・コンポーネントではアプリケーション・モジュールのロジックとして定義します。 トランザクション内のレコードと関連付けられた、現在コンポーネント・レコードPeopleCodeまたはコンポーネント・レコード・フィールドPeopleCodeとして記述しているロジックは、アプリケーション・モジュール内では定義されない可能性があります。ADFビジネス・コンポーネントには、複数のコンポーネントに同じレコードが使用されている場合に再使用しやすくするためのビュー・オブジェクトがあります。 つまり、PeopleToolsでは、コンテナの概念に対応したコンポーネントを使用しますが、ADFビジネス・コンポーネントでは、アプリケーション・モジュールを使用します。類似点はその部分のみです。コンポーネント・コードのすべてがアプリケーション・モジュールに移行するとは考えないでください。最初に、エンティティ・オブジェクトとアプリケーション・モジュール間のレイヤーであるビュー・オブジェクトの概念について理解します。次に、アプリケーション・モジュールに適したコンポーネント・コードの部分と、ビュー・オブジェクトに適した部分を決定します。 |
レコード定義 |
エンティティ・オブジェクト |
エンティティ・オブジェクトは、PeopleToolsレコード定義が基礎となる表やビューへのマッピングであるのと同様に、基礎となるデータ構造に対するマッピングです。一般的には、アプリケーション操作が必要な表ごとにエンティティ・オブジェクトを1つ作成します。 PeopleToolsの変換値を使用して「Customer Status」などのフィールドに有効な一連の値を宣言するのと同様に、ADFビジネス・コンポーネントではエンティティ・オブジェクトのそれぞれの属性に対し、宣言的な検証を追加できます。現在レコードPeopleCodeやレコード・フィールドPeopleCodeとして記述している、アプリケーション全体に適用されるレコードと関連付けられるすべてのロジックは、ADFビジネス・コンポーネントではエンティティ・オブジェクトとして定義できます。 |
行セット |
ビュー・オブジェクト |
PeopleToolsの行セットのように、ビュー・オブジェクトはSQL問合せにより移入できます。行セットと異なるのは、ビュー・オブジェクトの定義にはビジネス・ロジックを含めることができる点です。 コンポーネント・レコードPeopleCodeのロジックは、いずれもビュー・オブジェクトで定義される可能性があります。コンポーネント・レコードPeopleCodeはコンポーネントに直接関連付けられていますが、ビュー・オブジェクトは異なるアプリケーション・モジュールに関連付けることができます。多くのPeopleToolsコンポーネントでは同じレコード定義を使用できますが、Oracle ADFでは複数のアプリケーションにわたってビジネス・ロジックを再使用できます。 ビュー・オブジェクトは、現在のアプリケーションで使用しやすい形でデータの問合せを正確に行います。多くのビュー・オブジェクトは、同じエンティティ・オブジェクト上に構築できます。 PeopleToolsコンポーネントにおけるスクロール・レベルと同様に、マスター/ディテール構造を作成するため、ビュー・オブジェクト間の関係を定義できます。 |
Siebel Toolsバージョン7.0以前のバージョンを使用したソリューションの開発経験者には、使い慣れたすべてのデータ・アクセス機能が、多数の拡張機能とともに、ADFビジネス・コンポーネントに実装されていることがわかります。
表A-2 Siebel Tools開発者が理解しやすい概念
概念 | Oracle ADFへのマッピング | 類似点 |
---|---|---|
表オブジェクト |
エンティティ・オブジェクト |
Siebel表オブジェクトと同様に、ADFエンティティ・オブジェクトは、列名や物理的なデータ型など、1つの表の物理特性を表します。両方のオブジェクトには、データベース内の物理表を作成するデータ定義言語(DDL)を生成するために十分な情報が含まれています。ADFビジネス・コンポーネントでは、基礎となる表内の外部キーを反映した、エンティティ・オブジェクト間のアソシエーションを定義します。これらのアソシエーションは、ユーザー・インタフェース・ページで使用されるビュー・オブジェクト問合せにおいて、ビジネス情報を自動的に結合するために使用されます。データ列から参照する値リスト(LOV)オブジェクトは、宣言的なエンティティ・レベルの検証規則とビュー・オブジェクトの属性レベルのLOV定義の組合せによってADFビジネス・コンポーネントで処理されます。また、他の宣言またはプログラムによるビジネス・ロジックを、作成するすべてのデータ・ビューで自動的に再使用される表のハンドラ・エンティティ・オブジェクトとともにカプセル化することもできます。 |
ビジネス・コンポーネント |
ビュー・オブジェクト |
Siebelビジネス・コンポーネントのように、ADFビュー・オブジェクトは基礎となる物理表表現上に、論理マッピングを設定します。Siebelビジネス・コンポーネントとADFビュー・オブジェクトは、どちらもユーザー・インタフェースの要件を満たす、論理フィールド名、データ、計算済フィールドの提供を可能にします。Siebelビジネス・コンポーネントと同様、ADFビュー・オブジェクトでは、基礎となる様々な表の情報を結合するビュー・オブジェクトを定義できます。関連するADFビュー・リンクは、Siebelリンク・オブジェクトに類似しており、マスター/ディテール関係を定義できます。ADFビジネス・コンポーネントでは、データをユーザー・インタフェースで必要とされる形にするために、SQL言語の特性を十分に生かすようビュー・オブジェクトを定義できます。 |
ビジネス・オブジェクト |
アプリケーション・モジュール |
Siebelビジネス・オブジェクトでは、ビジネス・コンポーネントのコレクションを定義できます。ADFアプリケーション・モジュールでも同様のタスクが実行され、関連するユーザー・インタフェースのページの「データ・モデル」の役割を果すマスター/ディテール・ビュー・オブジェクトのコレクションを作成できます。さらに、アプリケーション・モジュールはこのデータ・ビュー・グループに対し、トランザクションおよびデータベース接続のコンテキストを提供します。アプリケーション・モジュールから取得したオブジェクトに対し複数のリクエストを行うことでき、これらは同じトランザクション内に含まれます。 |
Visual Studio 2003または2005を使用したソリューションの開発経験者は、ADO.NETフレームワークを使用したデータ・アクセスをよく理解しています。ADFビジネス・コンポーネントには、ADO.NETで使い慣れているすべてのデータ・アクセス機能が、様々な拡張機能とともに実装されています。
表A-3 ADO.NET開発者が理解しやすい概念
概念 | Oracle ADFへのマッピング | 類似点 |
---|---|---|
データ・セット |
アプリケーション・モジュール |
アプリケーション・モジュール・コンポーネントは、ADO.NETデータセットと同じ役割を果します。これは、ビュー・オブジェクト・インスタンスと呼ばれる行セットのコレクションを表す、強く型付けされたサービス・コンポーネントで、ADO.NETデータ表と類似しています。アプリケーション・モジュールによって、開発者による構成が可能な一連のビュー・インスタンスのデータの行を表すサービス・インタフェースが、SDOと互換性のあるサービス(Webサービス、またはSCAコンポジットとしてアクセス可能)として公開されます。アプリケーション・モジュールは、関連するトランザクション・オブジェクトと連携し、ビュー・オブジェクトが実行するSQL問合せのコンテキストを提供します。また、アプリケーション・モジュールは、ADO.NETデータ・アダプタの役割を果す、エンティティ・オブジェクトによってデータベースに保存された変更のコンテキストを提供します。 |
データ・アダプタ |
エンティティ・オブジェクト |
エンティティ・オブジェクト・コンポーネントは、強い型指定のADO.NETデータ・アダプタに類似しています。これは特定の表における行を表し、その行の主キーによる検索、挿入、更新、削除およびロックの操作を処理します。ADFビジネス・コンポーネントでは、これらの文を自分で記述する必要はありませんが、必要に応じてオーバーライドできます。エンティティ・オブジェクトは、属性や基礎となる表の行全体に関連する、検証や他のビジネス・ロジックをカプセル化します。検証は、エンド・ユーザーが基礎となるエンティティ・オブジェクトを参照するすべてのビュー・オブジェクト問合せを使用してデータを更新および保存したときに実行されます。ADFビジネス・コンポーネントの相違点としては、任意の柔軟な問合せがSQL文によってビュー・オブジェクト・インスタンス・レベルで実行されますが、ビュー・オブジェクトとエンティティ・オブジェクトが実行時に自動的に連携するという点があります。 |
データ・ブロック |
ビュー・オブジェクト |
ビュー・オブジェクト・コンポーネントは、データ・ブロック機能のうち、データの取得を実行します。各ビュー・オブジェクトではSQL問合せをカプセル化し、実行時にはそれぞれの問合せ結果セットを管理します。マスター/ディテール関連で2つ以上のビュー・オブジェクトを接続する場合、その調整は自動的に処理されます。ビュー・オブジェクトを定義する際、すべての問合せ列を、基礎となるエンティティ・オブジェクトにリンクさせることができます。この情報を取得することにより、ビュー・オブジェクトとエンティティ・オブジェクトは実行時に自動的に連携し、ユーザーのタスクで必要となるビジネス・データの形態にかかわらず、ドメインのビジネス・ロジックを実行します。 |