| Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2(11.1.2.3.0) B69399-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11g リリース2(11.1.2.3.0) B69399-02 |
|
前 |
次 |
この章ではOracle Application Development Framework(Oracle ADF)のADF Business Componentsレイヤーで作業を開始する際に使用できる主要な機能について説明します。また、ADF Business Componentsの実装アーキテクチャについて説明し、エンティティ・オブジェクトとビュー・オブジェクトでGroovyスクリプト言語に関するサポートについても説明します。
この章の内容は次のとおりです。
ADF Business ComponentsおよびJDeveloperを使用すると、Java EEプラットフォームのビジネス・アプリケーションを容易に開発、提供およびカスタマイズできます。開発者は、ADF Business Componentsを使用して次の作業を行う場合、通常のJava EEアプリケーションに必要なアプリケーションのインフラストラクチャ・コードを記述する必要はありません。
データベースへの接続
データの取得
データベース・レコードのロック
トランザクションの管理
ADF Business Componentsは、再利用可能なソフトウェア・コンポーネントのライブラリおよびJDeveloperの設計時機能のサポートを介してこれらのタスクを処理します。最も重要な点は、JDeveloperでの設計時に一般的な開発タスクを全体的に宣言的にするため、開発者はADF Business Componentsを使用して時間を節約できることです。特に、JDeveloperではADF Business Componentsによる宣言的開発をサポートし、次のタスクを行います。
自動的にデータベースと統合するコンポーネント内のビジネス・ロジックの、記述およびテスト
複数のアプリケーションタスクをサポートする、データの複数のSQLベースのビューを介したビジネス・ロジックの再使用
ブラウザ、デスクトップ、モバイル、Webサービス・クライアントからの、ビューへのアクセスおよび更新
配布したアプリケーションの修正を必要としないレイヤー単位のアプリケーション機能のカスタマイズ
ADF Business Componentsの目的は、ビジネス・サービス開発者の生産性をより高めることです。
ADF Business Componentsは、次の領域で提供される機能をビジネス階層アプリケーション・コンポーネントによって活用できる、Javaクラスの基盤を提供します。
必要なデータのみをクライアントに表示するデータ・モデルの設計
データ・モデルの一部としての複雑なマスター/ディテール階層の組込み
コード記述を必要としない、エンド・ユーザーのQuery-By-Example(QBE)データ・フィルタの実装
ビジネス・サービス・レイヤーとのデータ・モデル変更の自動調整
データベースに対する変更の自動検証および保存
必須フィールド、主キーの一意性、データの精度と規模および外部キー参照の宣言的な実行
マルチレベルでの検証サポートを含めた、プログラムまたは宣言による、簡単なビジネス・ルールと高度なビジネス・ルール両方の簡単な取得および実行
ビジネス・ドメイン・オブジェクト間の関係のナビゲートおよび複合コンポーネント関連の制約の実行
ビジネス・サービス・アプリケーション・ロジックによるユーザー・インタフェースにおける変更の自動反映
関連する表からの参照情報の取得と、ユーザーによる外部キー値の変更時の自動保持
Web階層の自動的な状態管理による、複数ステップのWebベース・ビジネス・トランザクションの簡略化
コードを必要としない、イメージ、ビデオ、音声およびドキュメントの処理
データの複数ビューにおける、保留中のデータ変更の同期化
複数アプリケーションにおける、プロンプト、ツールチップ、フォーマット・マスク、エラー・メッセージの一環した適用
メタデータ駆動型ユーザー・インタフェースまたはアプリケーション機能をサポートする、ビジネス・コンポーネントに対するカスタム・メタデータの定義
行単位の状態管理を簡略化する動的属性の、実行時の追加
コードを記述せずにビジネス統合できる高機能Webサービス・インタフェースのサポート
ベスト・プラクティスであるインタフェース・ベースのプログラミング・スタイルの適用
自動JAAS統合および監査メンテナンスによるアプリケーション・セキュリティの簡略化
「一度記述すれば、どこでも実行可能」: プレーンなJavaクラス、EJBセッションBean、Webサービスと同様のビジネス・サービスの使用
ソース・コードの変更を必要としない、提供後のコンポーネント機能の拡張
アプリケーションの修正を必要としない、提供済コンポーネントの拡張版へのグローバルな代替
カスタマイズが失われない、または下方カスタマイズの手動での再適用を必要としない、アプリケーション・アップグレードの提供
ADF Business Componentsは、次のコンポーネントと連携してビジネス・サービスを実装します。
エンティティ・オブジェクト
エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのデータ操作言語(DML)操作を処理することでデータ変更を簡略化します。また、該当する行のビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。
ビュー・オブジェクト
ビュー・オブジェクトは、SQL問合せを表します。使い慣れたSQL言語を十分に活用し、エンド・ユーザーのタスクが必要とする形に、データを正確に結合、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のビュー・オブジェクトにリンクし、複雑度にかかわらずマスター/ディテール階層を作成する機能も含まれます。エンド・ユーザーがユーザー・インタフェースを使用してデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。
アプリケーション・モジュール
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。
ベース・コンポーネントは、組込み動作によってすべての一般的なケースを処理しますが、カスタマイズはいつでも可能であり、ベース・コンポーネントで提供されるデフォルトの動作を簡単に上書きまたは補強できます。
ADF Business Componentsでは、エンタープライズ4GLツールと類似した機能を実装するコンポーネントを提供しています。ADF Business Componentsでは、複数の主要コンポーネントを、他の4GLツールで精通している概念上に位置付けています。
ADF Business Componentsは、ユーザー・インタフェースに依存しない方法で、使い慣れたOracle Formsのデータ中心のすべてのラインタイム機能を実装します。Oracle Formsの各フォームには、ビジュアルなオブジェクト(キャンバス、ウィンドウ、警告、LOVなど)と、ビジュアルでないオブジェクト(データ・ブロック、リレーション、レコード・グループなど)の両方が含まれます。各データ・ブロック項目には、Foreground Color、Bevelなどのビジュアルなプロパティと、Data Type、Maximum Lengthなどのビジュアルでないプロパティの両方が含まれます。Formsで定義される、様々なイベント処理のトリガーも、ビジュアルなものとビジュアルでないものに分けられます。たとえば、WHEN-BUTTON-PRESSEDやWHEN-MOUSE-CLICKEDなどはフロントエンドのUIに関連した本質的にビジュアルなトリガーであり、WHEN-VALIDATE-ITEMやON-INSERTなどはバックエンドのデータ処理に関連が深いトリガーです。ビジュアルな要素とビジュアルでない要素の統合によって、学習は容易になりますが、再使用は困難になる場合があります。UI関連の要素とデータ関連の要素を明確に分離することにより、バックエンドのビジネス・ロジックに影響を与えることなくユーザー・インタフェースを簡単に再設計できるほか、複数の異なるフォームのバックエンドのビジネス・ロジックの目的を容易に変更することができます。
UIとデータを分離して考えるために、フォームをビジュアルでないデータ関連の部分のみに削減することを検討してください。残るものはデータ・ブロックのコンテナ、リレーションおよびレコード・グループです。このコンテナは継続してデータ・ブロックに対してデータベース接続を提供し、トランザクションのコミットまたはロールバックを共有し、調整する役割を果します。ビジュアルでない検証およびトランザクション・トリガーを使用して、デフォルトのデータ処理の動作を拡張または変更することも引き続き可能です。ビジュアルでないオブジェクトとは、データおよびビジネス・ロジックはあるがユーザー・インタフェースの要素のない、スマート・データ・モデルまたは汎用アプリケーション・モジュールの一種です。このアプリケーション・モジュールは、すべてのビジュアル要素と分離することで、今後必要となるすべてのユーザー・インタフェースでこれらのモジュールをデータ・サービスとして使用可能にすることを目的としています。
このアプリケーション・モジュールで、データ・ブロックが果たす役割について考えます。データ・ブロックでは、SQLを使用してデータベースからデータ行の問合せを行います。また、マスター/ディテール関連と他のデータ・ブロックの調整、WHEN-VALIDATE-RECORDトリガーとWHEN-VALIDATE-ITEMトリガーを使用したユーザーによるデータ入力の検証、有効なユーザーによる変更について、データ・サービスのトランザクションのコミット時のINSERT、UPDATE、DELETE文でのデータベースとの通信などを行います。
経験上、エンド・ユーザーに対しては、各種のタスクに応じた様々な方法でデータのフィルタ処理、結合、ソートやグループ化を行う必要があると考えられます。一方、ビジネス・ドメイン・データに適用する検証規則は、基本的に変更されません。このような観点から、ビジネス・エンティティの検証は一度のみ記述し、これを常にアプリケーション内でのユーザーによるデータの操作に活用することをお薦めします。
こうした柔軟性を持たせるには、データ・ブロック機能をさらに「分割」する必要があります。アプリケーションで必要とされる数多くの異なるデータ・ビューを表すために必要なのは1種類の「SQL問合せ」オブジェクトのみで、ビジネス・ルールを順守し、一貫性のある方法で基礎となる表への変更のやり取りを行うために必要なのは別の種類の「ビジネス・エンティティ」オブジェクトです。このように機能を分割すると、特定のSQL問合せが同じビジネス・データを表している場合に、同一の基礎となる「エンティティ・オブジェクト」と連携する「ビュー・オブジェクト」を複数持つことができます。
Oracle Application Development Framework(Oracle ADF)では、一般的なForms機能を実装しすぐに使用できるJavaコンポーネントを提供することで、UI/データ分割を実現します。問合せとエンティティ関連で機能の役割が明確に区別され、より適切に再利用できます。
アプリケーション・モジュール・コンポーネントは、フォームのデータ部分です。アプリケーション・モジュールは、クライアント・インタフェースで処理が必要なマスター/ディテール関連の問合せに関するデータ・モデルを含む、スマート・データ・サービスです。また、これに含まれるコンポーネントで使用されるトランザクションとデータベース接続を提供します。このコンポーネントには、サービス実装においてカプセル化される、サービス・メソッドと呼ばれるフォーム・レベルのプロシージャおよびファンクションが含まれています。このプロシージャやファンクションのうち、どれをプライベートに設定し、どれをパブリックに設定するかを決定できます。
エンティティ・オブジェクト・コンポーネントは、前述のデータ・ブロック機能のうち、検証およびデータベース変更に関する部分を実装します。Formsの実行時には、この処理はレコード・マネージャによって実行されます。レコード・マネージャは、適切なタイミングでのブロック・レベルやアイテム・レベルでの検証トリガーの実行、およびデータベースへの変更の格納に関する調整を行うため、データ・ブロックのどの行が変更されたかを追跡します。この処理は、まさにエンティティ・オブジェクトが実行するものです。エンティティ・オブジェクトとは、基礎となるベース表によってビジネス・ドメインのエンティティを表すコンポーネントです。エンティティ・オブジェクトでは、ビジネス・オブジェクトの検証、デフォルト設定、データベース変更処理に関連するビジネス・ロジックをカプセル化するための場所を提供します。
ViewObjectコンポーネントは、データ・ブロック機能のうち、データの取得を実行します。各ビュー・オブジェクトではSQL問合せをカプセル化し、実行時にはそれぞれの問合せ結果セットを管理します。マスター/ディテール関連で2つ以上のビュー・オブジェクトを接続する場合、その調整は自動的に処理されます。ビュー・オブジェクトを定義する際、すべての問合せ列を、基礎となるエンティティ・オブジェクトにリンクさせることができます。この情報を取得することにより、ビュー・オブジェクトとエンティティ・オブジェクトは実行時に自動的に連携し、ユーザーのタスクで必要となるビジネス・データの形態にかかわらず、ドメインのビジネス・ロジックを実行します。
PeopleToolsを使用したソリューションの開発経験者は、PeopleToolsコンポーネントの構造をよく理解しています。ADF Business Componentsには、PeopleToolsで使い慣れているデータ・アクセス機能が実装されています。
Oracle ADFはMVCパターンに従い、ビューからモデルを分離します。PeopleToolsコンポーネントで使い慣れているページは、WebベースのアプリケーションのためのJSFコンポーネントやADF Facesコンポーネント、またはデスクトップ・フィデリティ・クライアント表示のためのSwingなどの標準テクノロジを使用し、ビュー・レイヤーで定義されます。
ADFアプリケーション・モジュールは、PeopleToolsコンポーネント・バッファと同様にデータ構造を定義します。データの行セットを生成するADF問合せコンポーネントとの間にマスター/ディテール関係を定義することにより、データと連携するすべてのアプリケーション・モジュールは、必要に応じて、コンポーネント・バッファのスクロール・レベルに類似した自然な階層を再使用できます。
使い慣れたコンポーネント・インタフェースと同様に、アプリケーション・モジュールは、標準メソッドおよび追加的な開発者定義ビジネス・ロジックへのアクセスを提供するサービス・オブジェクトです。特定のユーザー・インタフェースに対して「ヘッドレス」なデータ・サービスを提供するために、コンポーネント・インタフェースでは、UIの対話に関連するPeopleToolsのファンクションの数が制限されます。アプリケーション・モジュールは、「ヘッドレス」なデータ・サービスを提供するという点ではコンポーネント・インタフェースと類似していますが、既存のユーザー・インタフェースの制限されたビューをラップする手法ではデータを提供していません。かわりに、アプリケーション・モジュールはビジネス・ロジックとデータ・アクセスのみを処理するよう設計されています。ADF Business Componentsでは、コンポーネント上にコンポーネント・インタフェースを構築するのではなく、まずユーザー・インタフェースとは別のアプリケーション・モジュール・サービスを構築し、次にこのサービス上に1つ以上のページを構築して、アプリケーションのエンド・ユーザー・タスクを処理します。
アプリケーション・モジュールは、PeopleToolsコンポーネント・バッファと同じ方法でトランザクション・オブジェクトに関連付けられています。アプリケーション・モジュールは、自身に含まれているコンポーネントに対し、データベース接続を提供します。現在、コンポーネントPeopleCodeとしてトランザクションと関連付けているすべてのロジックは、ADF Business Componentsではアプリケーション・モジュールのロジックとして定義します。
トランザクション内のレコードと関連付けられた、現在コンポーネント・レコードPeopleCodeまたはコンポーネント・レコード・フィールドPeopleCodeとして記述しているロジックは、アプリケーション・モジュール内では定義されない可能性があります。ADF Business Componentsには、複数のコンポーネントに同じレコードが使用されている場合に再使用しやすくするためのビュー・オブジェクトがあります。
つまり、PeopleToolsでは、コンテナの概念に対応したコンポーネントを使用しますが、ADF Business Componentsでは、アプリケーション・モジュールを使用します。類似点はその部分のみです。コンポーネント・コードのすべてがアプリケーション・モジュールに移行するとは考えないでください。最初に、エンティティ・オブジェクトとアプリケーション・モジュール間のレイヤーであるビュー・オブジェクトの概念について理解します。次に、アプリケーション・モジュールに適したコンポーネント・コードの部分と、ビュー・オブジェクトに適した部分を決定します。
エンティティ・オブジェクトは、PeopleToolsレコード定義が基礎となる表やビューへのマッピングであるのと同様に、基礎となるデータ構造に対するマッピングです。一般的には、アプリケーション操作が必要な表ごとにエンティティ・オブジェクトを1つ作成します。
PeopleToolsの変換値を使用して「Customer Status」などのフィールドに有効な一連の値を宣言するのと同様に、ADF Business Componentsではエンティティ・オブジェクトのそれぞれの属性に対し、宣言的な検証を追加できます。現在レコードPeopleCodeやレコード・フィールドPeopleCodeとして記述している、アプリケーション全体に適用されるレコードと関連付けられるすべてのロジックは、ADF Business Componentsではエンティティ・オブジェクトとして定義できます。
PeopleToolsの行セットのように、ビュー・オブジェクトはSQL問合せにより移入できます。行セットと異なるのは、ビュー・オブジェクトの定義にはビジネス・ロジックを含めることができる点です。
コンポーネント・レコードPeopleCodeのロジックは、いずれもビュー・オブジェクトで定義される可能性があります。コンポーネント・レコードPeopleCodeはコンポーネントに直接関連付けられていますが、ビュー・オブジェクトは異なるアプリケーション・モジュールに関連付けることができます。多くのPeopleToolsコンポーネントでは同じレコード定義を使用できますが、Oracle ADFでは複数のアプリケーションにわたってビジネス・ロジックを再使用できます。
ビュー・オブジェクトは、現在のアプリケーションで使用しやすい形でデータの問合せを正確に行います。多くのビュー・オブジェクトは、同じエンティティ・オブジェクト上に構築できます。
PeopleToolsコンポーネントにおけるスクロール・レベルと同様に、マスター/ディテール構造を作成するため、ビュー・オブジェクト間の関係を定義できます。
Siebel Toolsバージョン7.0以前のバージョンを使用したソリューションの開発経験者には、使い慣れたすべてのデータ・アクセス機能が、多数の拡張機能とともに、ADF Business Componentsに実装されていることがわかります。
Siebel表オブジェクトと同様に、ADFエンティティ・オブジェクトは、列名や物理的なデータ型など、1つの表の物理特性を表します。両方のオブジェクトには、データベース内の物理表を作成するデータ定義言語(DDL)を生成するために十分な情報が含まれています。ADF Business Componentsでは、基礎となる表内の外部キーを反映した、エンティティ・オブジェクト間のアソシエーションを定義します。これらのアソシエーションは、ユーザー・インタフェース・ページで使用されるビュー・オブジェクト問合せにおいて、ビジネス情報を自動的に結合するために使用されます。データ列から参照する値リスト(LOV)オブジェクトは、宣言的なエンティティ・レベルの検証規則とビュー・オブジェクトの属性レベルのLOV定義の組合せによってADF Business Componentsで処理されます。また、他の宣言またはプログラムによるビジネス・ロジックを、作成するすべてのデータ・ビューで自動的に再使用される表のハンドラ・エンティティ・オブジェクトとともにカプセル化することもできます。
Siebelビジネス・コンポーネントのように、ADFビュー・オブジェクトは基礎となる物理表表現上に、論理マッピングを設定します。Siebelビジネス・コンポーネントとADFビュー・オブジェクトは、どちらもユーザー・インタフェースの要件を満たす、論理フィールド名、データ、計算済フィールドの提供を可能にします。Siebelビジネス・コンポーネントと同様、ADFビュー・オブジェクトでは、基礎となる様々な表の情報を結合するビュー・オブジェクトを定義できます。関連するADFビュー・リンクは、Siebelリンク・オブジェクトに類似しており、マスター/ディテール関係を定義できます。ADF Business Componentsでは、データをユーザー・インタフェースで必要とされる形にするために、SQL言語の特性を十分に生かすようビュー・オブジェクトを定義できます。
Siebelビジネス・オブジェクトでは、ビジネス・コンポーネントのコレクションを定義できます。ADFアプリケーション・モジュールでも同様のタスクが実行され、関連するユーザー・インタフェースのページの「データ・モデル」の役割を果すマスター/ディテール・ビュー・オブジェクトのコレクションを作成できます。さらに、アプリケーション・モジュールはこのデータ・ビュー・グループに対し、トランザクションおよびデータベース接続のコンテキストを提供します。アプリケーション・モジュールから取得したオブジェクトに対し複数のリクエストを行うことでき、これらは同じトランザクション内に含まれます。
Visual Studio 2003または2005を使用したソリューションの開発経験者は、ADO.NETフレームワークを使用したデータ・アクセスをよく理解しています。ADF Business Componentsには、ADO.NETで使い慣れているすべてのデータ・アクセス機能が、様々な拡張機能とともに実装されています。
アプリケーション・モジュール・コンポーネントは、ADO.NETデータセットと同じ役割を果します。これは、ビュー・オブジェクト・インスタンスと呼ばれる行セットのコレクションを表す、強く型付けされたサービス・コンポーネントで、ADO.NETデータ表と類似しています。アプリケーション・モジュールによって、開発者による構成が可能な一連のビュー・インスタンスのデータの行を表すサービス・インタフェースが、SDOと互換性のあるサービス(Webサービス、またはSCAコンポジットとしてアクセス可能)として公開されます。アプリケーション・モジュールは、関連するトランザクション・オブジェクトと連携し、ビュー・オブジェクトが実行するSQL問合せのコンテキストを提供します。また、アプリケーション・モジュールは、ADO.NETデータ・アダプタの役割を果す、エンティティ・オブジェクトによってデータベースに保存された変更のコンテキストを提供します。
エンティティ・オブジェクト・コンポーネントは、強く型付けされたADO.NETデータ・アダプタと同様のものです。これは特定の表における行を表し、その行の主キーによる検索、挿入、更新、削除およびロックの操作を処理します。ADF Business Componentsでは、これらの文を自分で記述する必要はありませんが、必要に応じて上書きできます。エンティティ・オブジェクトは、属性や基礎となる表の行全体に関連する、検証や他のビジネス・ロジックをカプセル化します。検証は、エンド・ユーザーが基礎となるエンティティ・オブジェクトを参照するすべてのビュー・オブジェクト問合せを使用してデータを更新および保存したときに実行されます。ADF Business Componentsの相違点としては、任意の柔軟な問合せがSQL文によってビュー・オブジェクト・インスタンス・レベルで実行されますが、ビュー・オブジェクトとエンティティ・オブジェクトが実行時に自動的に連携するという点があります。
ビュー・オブジェクト・コンポーネントは、SQL問合せをカプセル化し、結果となる行セットを管理します。基礎となるエンティティ・オブジェクトと関連付けることにより、ユーザーによるそれらの行の検証や変更の保存を自動的に調整します。ビュー・オブジェクトの問合せデータと、エンティティ・オブジェクトのカプセル化されたビジネス・ロジックの連携により、データ表のすべての利点に加え、ビジネス・ドメイン・オブジェクトのレイヤーに対するビジネス・ロジックの明確なカプセル化が可能になります。ADO.NETデータテーブルのように、ビュー・オブジェクトのデータをXMLとして簡単に扱うこと、およびビュー・オブジェクトでXMLデータを読み込み、その情報に基づいた行の挿入、更新または削除などを自動的に行うことができます。
JDeveloperは、ADF Business Componentsに対する包括的な設計時サポートを提供します。これらの機能では、ビジネス・コンポーネントの作成、編集、ダイアグラム表示、テストおよびリファクタを一括して実行できます。
最初にコンポーネントを作成する場合は、図3-1に示すように、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示されます。このダイアログでは、このデータ・モデル・プロジェクト(ADF Business Components用に作成されるプロジェクトでこのマニュアルで使用される用語)のビジネス・コンポーネントで作業する際に使用するために、設計時のアプリケーション・リソース接続を選択したり、既存のIDEレベルの接続をコピーして新規のアプリケーション・リソース接続を作成します。
このダイアログは最初のビジネス・コンポーネントを作成する前に表示されるため、これを使用して、ビュー・オブジェクトがSQL文を策定するために使用するSQLプラットフォームをグローバルに制御します。Oracleデータベース接続のデフォルトは常にOracle SQLプラットフォームですが、選択できる他のSQLプラットフォームには、OLite(Oracle Liteデータベースの場合)、SQLServer(Microsoft SQLServerデータベースの場合)、DB2(IBM DB2データベースの場合)、SQL92(その他のサポートされたSQL92準拠のデータベースの場合)があります
|
注意: OracleデータベースとOracle以外のデータベースの両方に対してアプリケーションを実行する予定がある場合、後ではなくアプリケーションを構築し始める際に、SQL92 SQLプラットフォームを選択する必要があります。これにより、Oracle SQLプラットフォームを使用する場合に特有の、Oracle固有の最適化機能の一部は使用できなくなりますが、OracleデータベースとOracle以外のデータベースの両方に適用できるアプリケーションを構築できます。 |
このダイアログでは、データ・モデル・プロジェクトで使用するデータ型のセットも決定できます。JDeveloperでOracleデータベース・ドライバの使用が検出されると、「データ型マップ」 の設定はデフォルトで「Oracle用拡張Java」型マップに設定され、標準のJava型と最適化された型がoracle.jbo.domainパッケージで一般的なデータ型用に使用されます。Oracle以外のデータベース上で実行する予定のSQL92準拠アプリケーションを作成すると、データ型マップを「Java」設定に変更して、グローバルに基本Javaデータ型のみを使用できます。
「Oracle用拡張Java」型マップと「Oracleドメイン」型マップとでは、数値データの処理が異なります。新しいアプリケーションを作成する際、デフォルト型マップの「Oracle用拡張Java」により数値データをjava.math.BigDecimalクラスにマップし、java.math.Numberから継承します。java.math.BigDecimalのデフォルト値は、Fusion Webアプリケーションのビュー・レイヤの方法に一致し、ADF Facesコンポーネントで構成されますが、数値データ(WebページでADF Faces入力フィールドにより表示される数値など)の位置合せが維持されます。「Oracleドメイン」型マップでは数値データをoracle.jbo.domain.Numberクラスにマップしますが、ADF Facesコンポーネントで期待される位置合せでデータは表示されない場合があります。この位置合せ問題とは別にして、「Oracleドメイン」型マップは有効な選択肢であり、ADF Facesコンポーネントのないアプリケーションは問題なく機能します。
新しいFusion Webアプリケーションでは、デフォルトの「Oracle用拡張Java」型を使用する必要があります。下位互換性を保つためや、ADF Facesをビュー・レイヤー・テクノロジとして使用していないアプリケーションのために、「Oracleドメイン」型マップが用意されています。JDeveloperリリース11.1.1.4.0以前で開発されたアプリケーションを移行する際、アプリケーションでは引き続き「Oracleドメイン」型マップが使用され、現在のデフォルト型マップの「Oracle用拡張Java」に変更されません。
データ・モデル・プロジェクトを初期化した後にデータ型マップを変更できません。データ・モデル・プロジェクトを初期化すると、adf-config.xmlファイルの概要エディタでSQLプラットフォームをオーバーライドできます。adf-config.xmlファイルでデータベース・タイプを指定すると、実行時にそのデータベース・タイプを要求できるSQL文の生成がサポートされます。このファイルは、「アプリケーション・リソース」パネルで「ディスクリプタ」→ADF META-INFノードを展開して特定できます。
「新規ギャラリ」の「ADF Business Components」カテゴリでは、JDeveloperはそれぞれのビジネス・コンポーネントを作成するためのウィザードを提供しています。各ウィザードでは、新規コンポーネントのコンポーネント名を指定し、どのパッケージにコンポーネントを配置するかを選択できます。パッケージがまだ存在しない場合、新規コンポーネントがそのパッケージの最初のコンポーネントになります。
ウィザードには、コンポーネント・タイプを作成するために必要な情報を収集する、一連のパネルが表示されます。「終了」をクリックすると、XMLコンポーネント定義ファイルが保存され、新規コンポーネントが作成されます。デフォルトでクラス生成にJava生成オプションを設定している場合、JDeveloperでは初期のカスタムJavaクラス・ファイルも同時に作成されます。
アプリケーション・ナビゲータ内にパッケージを含めた後は、アプリケーション・ナビゲータからパッケージを選択し、図3-2に示すポップアップ・メニューからオプションを選択することで、追加の各種ビジネス・コンポーネントを迅速に作成できるようになります。
コンポーネントが作成された後は、「アプリケーション・ナビゲータ」でコンポーネントをダブルクリックするか、コンポーネントを選択し、ポップアップ・メニューから「編集」オプションを選択して概要エディタを起動し、編集することができます。概要エディタには、ウィザードに表示されるのと同じ編集オプションが表示されますが、表示項目の配置が異なる場合があります。概要エディタでは、コンポーネントのすべての特徴を変更できます。「OK」をクリックすると、コンポーネントのXMLコンポーネント定義ファイルが更新され、関連するすべてのカスタムJavaファイルが必要に応じて更新されます。概要エディタは、モーダル・ダイアログではなくJDeveloperの編集ウィンドウであるため、必要な数のコンポーネントの概要エディタを開いて表示できます。
プロジェクトが定義するビジネス・コンポーネントの数が増大すると、コンポーネントをリファクタして、最初に作成された関係を変更する場合があります。データ・モデル・プロジェクトにおける複数のコンポーネントの関係を把握するには、コンポーネントをエディタ・ウィンドウで開き、「ダイアグラム」タブをクリックします。エディタの関係ダイアグラムでは、編集するコンポーネントを太字で識別します。関連コンポーネントは、クリックするとリンクで識別されるコンポーネントを表示できるテキスト・リンクとして表示されます。たとえば、図3-3は、ProductsVOビュー・オブジェクトのエディタの「ダイアグラム」タブを示しています。ProductsVOがアクセスできるエンティティ・オブジェクト(たとえば、ProductBaseEOやProductTranslationEOなど)のリスト、関連ビュー・オブジェクトに対するビュー・オブジェクトの関係を定義するビュー・リンク(ProductsToWarehouseStockLevels)、およびビュー・リンクにより命名された関連ビュー・オブジェクト(WarehouseStockLevelsVO)をダイアグラムにより識別します。これらの各関連コンポーネントは、クリックするとエディタの「ダイアグラム」タブでコンポーネントを開くことができるリンクとして表示されます。関連コンポーネントのリンクをクリックすると、ダイアグラムを使用して、プロジェクトで定義するコンポーネント関係にナビゲートできます。
JDeveloperでは、ADF Business Componentsに対する充実したUMLダイアグラム・サポートが提供されます。作成済の既存のコンポーネントは、ビジネス・コンポーネント・ダイアグラムに追加して視覚化できます。また、コンポーネントの作成および変更にダイアグラムを使用することもできます。ダイアグラムは、エディタでの変更と同期しています。
新しいビジネス・コンポーネント・ダイアグラムを作成するには、JDeveloperの「新規ギャラリ」の「ADF Business Components」カテゴリから、「ビジネス・コンポーネント・ダイアグラム」アイテムを使用します。このカテゴリは、Business Tierの選択肢の一部です。
アプリケーション・モジュール・コンポーネントの作成後は、組込みのOracle ADFモデル・テスターを使用し、繰り返しテストできます。Oracle ADFモデル・テスターを起動するには、「アプリケーション・ナビゲータ」またはビジネス・コンポーネント・ダイアグラムでアプリケーション・モジュールを選択し、ポップアップ・メニューから「実行」または「デバッグ」を選択します
Oracle ADFモデル・テスターではアプリケーション・モジュールのデータ・モデルにビュー・オブジェクト・インスタンスを提供し、動的に生成されるユーザー・インタフェースを使用してユーザーとインスタンスとの対話を可能にします。このツールでは、アプリケーション・モジュールのクライアント・インタフェース・メソッドのリストも提供され、アプリケーション・モジュールのノードをダブルクリックすると、対話的にテストできます。このツールは、Webページのビュー・レイヤー作成の前後において、ビジネス・サービスのテストやデバッグに必要不可欠なものです。
「アプリケーション・ナビゲータ」でコンポーネントを選択し、ポップアップ・メニューから「リファクタ」→「名前の変更」を選択すると、いつでもコンポーネントの名前を変更できます。構造ウィンドウには、アプリケーション・モジュール・データ・モデルのビュー・オブジェクト属性やビュー・インスタンスなど、アプリケーション・ナビゲータには表示されないコンポーネントの詳細のための「名前の変更」ポップアップ・メニュー・オプションも表示されます。また、ナビゲータ内で[Ctrl]キーを押しながらクリックして1つ以上のコンポーネントを選択し、次にポップアップ・メニューから「リファクタ」→「移動」を選択すると、選択したコンポーネントを新規パッケージに移動できます。現在のデータ・モデル・プロジェクト内の古いコンポーネント名やパッケージへの参照は、自動的に修正されます。
ビジネス・サービスの実装における、ADF Business Componentsを使用した簡略化の主要な利点の1つは、アプリケーション・モジュールが行セットのアクティブ・データ・モデルをサポートしている点です。各ビジネス・オブジェクトの行セットにはデータが含まれていますが、データ・モデルはアプリケーション固有のビジネス・オブジェクトを定義します。アプリケーションのUI部分において、UIコンポーネントはビジネス・オブジェクトと対話し、取得、作成、編集および削除の操作を実行します。ADF ModelレイヤーとADF Faces UIコンポーネントを組み合せてADF Business Componentsを使用する場合、UIコンポーネントは自動的に更新してビジネス・オブジェクトの行セットに対する変更を反映するため、データ・モデルはアクティブになります。
このように、アクティブ・データ・モデルは、UIとデータ・モデルが常に同期するよう、アプリケーション・テクノロジ・レイヤー全体に渡って動作するソリューションを表します。
一般的なJava EEビジネス・サービスの実装を使用する場合、クライアントの開発者は次の点に留意する必要があります。
データを再表示するため、サービス・メソッドを起動します。
クライアントがどのデータを作成、削除、変更したかを追跡します。
変更を検証および保存するため、変更を1つ以上の異なるサービス・メソッドに渡します。
取得、作成、編集、削除および保存は、アプリケーション開発で実行される一般的な一連のタスクです。結果として、ADFアプリケーション・モジュールは、より高度で汎用的なソリューションを示します。ビジネス・サービスでアプリケーション・モジュールを使用すると、フィールド、表、ツリーなどのクライアントUIコンポーネントを、アプリケーション・モジュールのデータ・モデルにおけるアクティブ・ビュー・オブジェクト・インスタンスにバインドするのみですみます。Webやモバイル・デバイス用のJSPまたはJSFページのUIコンポーネント(Swingを使用した、ウィンドウやパネルから構成されるデスクトップ・フィデリティのUIも含む)は、データ・モデルのビュー・オブジェクト行セットの行に対する変更を反映するよう自動的に更新されます。さらに、データ・モデルのビュー・インスタンスに対する変更を生成するアプリケーション・モジュール用にカスタム・ビジネス・サービス・メソッドを定義すると、これらの変更も自動的にUIコンポーネントに反映されます。
アプリケーション・モジュール・コンポーネントは一連の汎用サービス・メソッドを実装するため、ユーザーは、サービス指向アーキテクチャ(SOA)でアクティブ・データ・モデルを活用できます。WebサービスおよびUIクライアントは、単純なAPIを使用してアプリケーション・モジュールのデータ・モデルに容易にアクセスできます。これらのAPIにより、アプリケーション・モジュールで利用可能な任意の情報を検索および修正できます。
宣言的なデータバインドのためのADF Modelレイヤーを活用するUIを構築する場合、一般的に、クライアント側のコードを記述する必要はありません。アクティブ・データ・モデルでは、WebページのUIコンポーネントをデータ・モデルのビュー・オブジェクトに宣言的にバインドする処理と、カスタム・ビジネス・サービス・メソッドに宣言的にバインドする処理がサポートされています。さらに、WebサービスをSOA環境で作成すると、データ・モデルのWebサービス・インタフェースによりデータ・モデルに宣言的にバインドできます。
アクティブ・データ・モデルがない場合、日常的に使用する単純なCRUDスタイル操作を処理するには、クライアントやWebサービス側でより多くのコードを記述する必要があります。さらに、ページを常に最新に保つために「リフレッシュ・フラグ」を管理し、変更された可能性のあるデータを反映するためのビジネス・サービスからのデータ再取得リクエストをコントロール・レイヤーに通知する必要があります。ADFアプリケーション・モジュールを使用してビジネス・サービスを実装する場合、エンド・ユーザーの期待どおりに業務を処理するための調査を行うかわりに、ビジネス・ロジックに焦点を当てることができます。
アクティブ・データ・モデルの、次の3つの具体的な例について検討します。
新規データの対応する画面への、再問合せなしの表示
顧客がFusion Order Demoアプリケーションにログインすると、ショッピング・カートの項目のリストが表示されます。次に製品ページから発注項目を新たに作成し、ショッピング・カートに戻ると、アプリケーションでデータベースに再問合せしなくても、新規項目がリスト内に表示されます。
ビジネス・ドメイン・ロジックによる変更の自動反映
バック・オフィス・アプリケーションによって、発注状況が更新されます。ビジネス・ドメイン・レイヤーのOrdersエンティティ・オブジェクトにカプセル化されたビジネス・ロジックには、発注状況の属性に変更があった場合は常に最新更新日を更新する簡単なルールが含まれています。ユーザー・インタフェースは、ビジネス・ドメイン・レイヤーのロジックが変更された最新更新日を自動的に反映するよう更新されます。
ADFモデル・レイヤーのバインディングによりビジネス・サービス・メソッドが起動されると、データの再問合せと現在行の設定が実行されます。
ツリー表示で、ユーザーがツリー内のあるノードをクリックします。この操作により、アプリケーション・モジュール内のADFツリー・バインディングでビジネス・サービス・メソッドが宣言的に起動され、マスター/ディテール情報の再問合せが実行され、行セットの適切な行に現在行を設定します画面は新規マスター/ディテール・データと現在行の表示を反映するよう更新されます。
アプリケーション・モジュールはアクティブ・データ・モデルをサポートしているため、クライアント・ユーザー・インタフェースは常に最新に保たれます。つまり、データ・モデルの設定または操作に関連するクライアント側のコードを記述する必要がありません。
ADF Business Componentsの使用によって記述が不要になるクライアント側コードの一般的な型としては、他に、マスターの行が変更された場合の詳細データ・コレクションを調整するコードがあります。ビュー・オブジェクトをリンクすることにより、この調整は自動的に実行されます。
ただし、カスタム・コードを記述する必要がある場合は、アプリケーション・モジュール・コンポーネントのカスタム・メソッド内でこのコードをカプセル化してください。たとえば、ビュー・オブジェクトを操作するプログラム的なコードが完全なビジネス・サービス機能を実装するための論理的な特徴を備えている場合、アプリケーション・モジュールのJavaクラスでカスタム・メソッドを記述して、詳細をカプセル化する必要があります。これには次のコードが考えられますが、これらのコードに限定されるものではありません。
表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成
集計結果を取得するための、ビュー・オブジェクト行の反復処理
1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行
これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。
コードの目的が、クライアントにより明確に伝わります。
必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。
ビジネス・サービス機能全体の回帰テストを簡略化できます。
クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。
ページ内での論理的ビジネス機能の宣言的起動が可能になります。
特定のADF Business Components実装を開始する前に、ADF Business Componentsの設計および実装に関してよく理解しておくことをお薦めします。
ADF Business Componentsは、Oracle ADFのすべてのテクノロジと同様、Javaで実装されています。コンポーネントはフレームワーク内で動作し、テストされ、堅牢なコードの豊富なレイヤーから汎用性の高いメタデータ駆動型の機能を提供します。ADF Business Componentsは、Java EEコミュニティのベスト・プラクティスに準拠しており、明確に分離されたXMLファイル内に各コンポーネントの実行時の動作を構成するために定義したメタデータが保持されています。
ADF Business Componentsはビジネス上非常に重要なアプリケーションにおいて使用されることが多いため、サポート契約を締結しているお客様は、ADF Business Componentsを含めてOracle ADFの完全なソースをOracle Worldwide Supportから入手できます。36.8項「ADF宣言デバッガの使用」で説明されているように、Oracle ADFの完全なソースコードは、問題の診断に役立つ重要なツールです。12.4項「拡張クラスによるフレームワークの動作のカスタマイズ」で説明されているように、Oracle ADFの完全なソース・コードを使用すると、必要に応じてベース・フレームワーク機能を適切に拡張する方法を理解するためにも役立ちます。
ADF Business Componentsを使用して構築されたアプリケーションは、Java EE準拠のアプリケーション・サーバーを含む、Java対応のすべてのアプリケーション・サーバーで実行可能です。ビジネス・コンポーネントは、プレーンなJavaクラスとXMLファイルを使用して実装されているため、Java仮装マシンが存在するすべての実行環境で使用可能です。つまり、ADF Business Componentsを使用して構築されたサービスは、実行時にアプリケーションのコンテナと呼ばれるJava EEサーバーの内部と、サーバーの外部の両方で簡単に使用できます。
顧客は、コマンドラインのバッチ・プログラム、Webサービス、カスタム・サーブレット、JSPページ、Swingによって構築したデスクトップ・フィデリティ・クライアントなど、様々な構成でアプリケーション・モジュールを日常的に使用します。
また、3.3.1項「接続、SQLプラットフォームおよびデータ型マップの選択」で説明されているように、Oracle以外のデータベースと連携するアプリケーションを構築できますが、Oracleデータベースを対象とするアプリケーションでは、ADF Business Componentsに対して様々な最適化が構築されています。
ADF Business Componentsは一般的なJava EEデザイン・パターンのすべてを実装しており、それらは、実際のエンタープライズJava EEアプリケーション作成のために理解、実装およびデバッグする必要があります。ADF Business Componentsデザイン・パターンにおけるJava EE仕様のこれらのデザイン・パターンの名称のクロス・リファレンスが必要な場合は、付録E「ADF Business Components Java EEデザイン・パターン・カタログ」を参照してください。
ADF Business ComponentsはJavaで実装されているため、クラスおよびインタフェースはパッケージ化されています。Javaパッケージは、ピリオドで区切った名前で識別され、開発者は階層型のネーミング構造でコードを整理できます。
ADF Business Componentsにより提供されたソース・コードを構成するクラスおよびインタフェースは、oracle.jboパッケージおよび多数のサブパッケージに含まれます。ただし、ADF Business Componentsを使用した日常作業においては、主に次の2つの主要パッケージに含まれるクラスやインタフェースを使用します。
ビジネス・サービス・クライアントの連携のために設計されたすべてのインタフェースが含まれる、oracle.jboパッケージ
これらのインタフェースを実装するクラスが含まれるoracle.jbo.serverパッケージ
|
注意: ここでのクライアントという用語は、ビジネス・サービスとしてアプリケーション・モジュール・コンポーネントにアクセスするモデル・レイヤー、ビュー・レイヤーまたはコントローラ・レイヤー内のコードを意味します。 |
図3-4に、アプリケーション・モジュール・コンポーネントの具体的な例を示します。アプリケーション・モジュールのためのクライアント・インタフェースは、oracle.jboパッケージの中のApplicationModuleインタフェースです。このインタフェースは、クライアントがアプリケーション・モジュールとの連携に利用可能なメソッドの名前やシグネチャを定義しますが、その機能の実装の仕様は含まれていません。アプリケーション・モジュール・コンポーネントのベースとなる機能を実装するクラスは、oracle.jbo.serverパッケージに含まれているApplicationModuleImplというクラスです。
ADF Business ComponentsはJavaで実装されているため、クラス、インタフェース、およびメタデータ・ファイルなどアプリケーションのコンポーネントもパッケージ化されます。
コンポーネントが他の組織の再使用可能なコンポーネントと競合しないように、パッケージ名の先頭に組織名またはWebドメイン名を付けます。たとえば、Apacheでは、Tomcat Webサーバーと関連付けるためにパッケージ名としてorg.apache.tomcatを指定しており、Oracleでは、XML Parserのパッケージ名としてoracle.xml.parserを指定しています。自社アプリケーション用に作成したコンポーネントは、com.yourcompany.yourappなどの名前でパッケージおよびそのサブパッケージに配置されます。
具体的な例として、Fusion Order Demoアプリケーションの主要なビジネス・サービスを構成するADF Business Componentsは、oracle.fodemo.storefrontパッケージおよびサブパッケージに配置されています。図3-5に示すように、これらのコンポーネントはStoreFrontModuleアプリケーションのStoreFrontServiceプロジェクトにあり、次のように幅広く配置されています。
oracle.fodemo.storefront.account.queriesには、顧客登録プロセスで使用されるビュー・オブジェクトが含まれています。
oracle.fodemo.storefront.clientには、テスト・クライアント.javaファイルが含まれています。
oracle.fodemo.storefront.entitiesには、エンティティ・オブジェクトが含まれています。
oracle.fodemo.storefront.lookupsには、静的なデータ・ビュー・オブジェクトととLookupServiceAM共有アプリケーション・モジュールが含まれています。
oracle.fodemo.storefront.store.queriesには、ストアフロントの管理に使用されるビュー・オブジェクトが含まれています。
oracle.fodemo.storefront.store.serviceには、StoreServiceAMアプリケーション・モジュールが含まれています。
自社アプリケーションでは、最適なパッケージ構成を選択できます。具体的には、同じタイプのコンポーネントを1つのパッケージにまとめる必要はありません。
JDeveloperはコンポーネントのリファクタをサポートしているため、名前の変更や、コンポーネントの別のパッケージへの移動などはいつでも簡単に行うことができます。この柔軟性によって、アプリケーションが発展するにつれて、必要な変更を簡単に加えることができます。
パッケージに最適なコンポーネント数はありません。ただし、経験を重ねるにつれ、チームに最適な構造が二極間(すべてのコンポーネントを1つのパッケージまとめる構造と各コンポーネントを個々のパッケージに分ける構造)のどこかに収まることがわかります。
プロジェクトは、他のデータ・モデル・プロジェクトでの再使用のためにJDeveloperがサポートする最小レベルの単位であることを考慮に入れる必要があります。そのため、コンポーネントをどのように配置するかを考慮する場合もあります。詳細は、38.2項「ADFライブラリへの再利用可能なADFコンポーネントのパッケージ化」を参照してください。
ADF Business Componentsの各コンポーネントには、宣言的な設定によって制御される、組込みランタイム機能が付属しています。これらの設定は、コンポーネントと同じ名前のXMLコンポーネント定義ファイルに格納されています。コンポーネントの動作を拡張するなど、コンポーネントのカスタム・コードを記述する必要がある場合、該当するコンポーネントに対するオプションのカスタムJavaクラスを有効にできます。図3-6は、アプリケーション・モジュールに対するXMLコンポーネント定義およびオプションのカスタムJavaクラスがアプリケーション・ナビゲータでどのように表示されるかを示しています。
図3-7は、com.yourcompany.yourappパッケージ内で作成した、アプリケーション・モジュールYourServiceなどのアプリケーション固有のコンポーネントに対するXMLコンポーネント定義ファイルを示しています。対応するXMLコンポーネント定義は、データ・モデル・プロジェクトのソース・パスのルート・ディレクトリ内のサブディレクトリ./com/yourcompany/yourappに保存されます。そのXMLファイルには、実行時にアプリケーション・モジュール実装を提供するJavaクラスの名前が記録されます。この場合、XMLにはOracle ADFが提供するoracle.jbo.server.ApplicationModuleImplベース・クラスの名前が記録されます。
カスタマイズを行わずに使用した場合、コンポーネントは、XMLコンポーネント定義で完全に定義されており、コンポーネントのカスタムJavaコードやJavaクラス・ファイルをまったく必要とせず、十分な機能を備えています。ADF Business Componentsのコンポーネントの組込み機能を拡張する必要がない場合、また、組込みイベントを処理するカスタム・コードを記述する必要がない場合、このXMLのみの方法でコンポーネントを使用できます。
コンポーネントのベース機能を拡張するため、またはイベントを処理するためにカスタム・コードを追加する必要がある場合、作成するADF Business Componentsのすべての主要タイプに対し、カスタムJavaクラスを有効にできます。コンポーネントのカスタム・クラスの生成は、JDeveloperの対応する概要エディタの「Java」ページで有効にします。このオプションを有効にすると、JDeveloperにより、構成可能な命名の標準に準拠したコンポーネントに関連するカスタム・クラスのJavaソース・ファイルが作成されます。このクラスの名前は、コンポーネントのXMLコンポーネント定義に記録され、コンポーネントで必要とされるカスタムJavaコードは、このクラス内に記述できます。コンポーネントに対してカスタムJavaクラスを有効にすると、コンポーネントの「アプリケーション・ナビゲータ」のポップアップ・メニューから、対応する「componentNameクラスに移動」オプションを使用してそこにナビゲートできます。
図3-8は、YourServiceアプリケーション・モジュールに対してカスタムJavaクラスを有効にするとどうなるかを示しています。YourServiceImpl.javaソース・コード・ファイルが、コンポーネントのXMLコンポーネント定義ファイルと同じソース・パスの同じディレクトリに作成されます。YourServiceImpl.xmlファイルでは、ApplicationModuleImplクラスではなく、com.yourcompany.yourapp.YourServiceImplベース・クラスを実行時に使用するよう、変更が反映されます。
|
注意: このガイドの例では、生成済のカスタム・コンポーネント・クラスやインタフェースの名前には、デフォルトの設定を使用しています。自社アプリケーションでこれらのデフォルトを変更するには、JDeveloperの「設定」ダイアログの「ADF Business Components: クラス・ネーミング」ページを使用してください。ここでの変更は、新しく作成したコンポーネントにのみ反映されます。 |
Java言語は文字列、日付、数値などのデータを処理するため、数多くの組込みデータ型を備えています。ADF Business Componentsにおいても、これらの型を使用可能ですが、デフォルトではoracle.jbo.domainパッケージおよびoracle.ord.imパッケージで最適化した一連の型を使用します。表3-1で示すように、これらの型によって、Oracleデータベースからアクセスしたデータをネイティブな内部形式でデータに保持することができます。ADF Business Componentsで提供される最適化されたデータ型を使用し、不要な型変換をなくして処理パフォーマンスを向上させます。
最適化されたデータ型がデフォルトで使用されずに、Java組込みデータ型で代用される場合が2つあります。文字列データでの作業の場合、ADF Business Componentsではデフォルトで通常のjava.lang.String型を使用します。さらに、数値データで作業するには、デフォルトでADF Business Componentsではjava.math.BigDecimal型を使用して、ADF Facesコンポーネントで期待される位置合せと整合する方法で数値を書式設定します。下位互換性を保つ場合や、ADF Facesコンポーネントを使用していないアプリケーションの場合、以前のリリースで用意されていた最適化データ型であるoracle.jbo.domain.Numberは、数値データの代替データ型のままになっています。
表3-1oracle.jbo.domainパッケージおよびoracle.ord.imパッケージでの基本データ型
| データ型 | パッケージ | 説明 |
|---|---|---|
|
|
|
すべての数値データデフォルトで、ADF Business Componentsでは |
|
|
|
日付および(オプションの)時間 |
|
|
|
データベース・トリガーにより割り当てられた、連続した整数 |
|
|
|
OracleデータベースのROWID |
|
|
|
タイムスタンプ値 |
|
|
|
タイムスタンプ値およびタイム・ゾーン情報 |
|
|
|
JavaVMまたはADF Context(アプリケーションの <user-time-zone-config xmlns= "http://xmlns.oracle.com/adf/usertimezone/config"> <user-timezone expression= "EL exp" /> </user-time-zone-config> このEL式が評価されて現在のユーザーのタイム・ゾーンが決定されるか、この値はJavaVMのタイム・ゾーンにデフォルト設定されます。 |
|
|
|
バイナリ・ファイル(BFILE)オブジェクト |
|
|
|
バイナリ・ラージ・オブジェクト(BLOB) |
|
|
|
キャラクタ・ラージ・オブジェクト(CLOB) |
|
|
|
Oracle Intermediaイメージ(ORDIMAGE) |
|
|
|
Oracle Intermediaオーディオ(ORDAUDIO) |
|
|
|
Oracle Intermediaビデオ(ORDVIDEO) |
|
|
|
Oracle Intermediaドキュメント(ORDDOC) |
|
|
|
ユーザー定義オブジェクト・タイプ |
|
|
|
ユーザー定義コレクション・タイプ(例: |
|
注意: ADF Facesをビュー・レイヤー・テクノロジとして使用していない場合、 import oracle.jbo.domain.Number; クラスの先頭の |
アプリケーション・モジュール、ビュー・オブジェクトやエンティティ・オブジェクトで作業を行う際、汎用APIを使用するか、そのコンポーネントに強く型付けされたAPIを有効にするために、JDeveloperでコードをカスタムJavaクラスに生成できます。たとえば、ビュー・オブジェクトでの作業中、次のような汎用APIを使用し、結果のすべての行の属性値にアクセスできます。
Row row = ordersVO.getCurrentRow();
Date shippedDate = (Date)row.getAttribute("OrderShippedDate");
汎用APIを使用した場合、パラメータの文字列名をアクセッサに渡し、戻り値の型をこの例のDateのように予想される型にキャストする必要があります。
一方、強く型付けされた作業スタイルを有効にした場合、次のようにコードを記述できます。
OrdersRow row = (OrdersRow)ordersVO.getCurrentRow(); Date shippedDate = row.getOrderShippedDate();
この場合、文字列名を渡して結果をキャストするのではなく、戻り型がコンパイル時に判明する生成済メソッド名を使用します。コンパイル時の安全性を犠牲にせずに、ビジネス・ロジック・コードからメソッドを起動する必要がある場合は、通常、強く型付けされたアクセッサを使用する必要があります。この方法は、setterメソッド内でカスタム検証ロジックを記述する場合にも役立ちますが、この場合は、Business Componentsでエンティティおよびビュー行実装クラスを生成するかわりに、Groovy式の使用を検討する必要が生じる場合もあります。後続の章では、Javaを使用した実装を選択するビジネス・ロジックのJavaクラスを生成して、強く型付けされた作業スタイルを有効化する方法について説明します。
ビジネス・サービスの次のコンポーネントのみがクライアントに表示されます。
アプリケーション・モジュール: サービス自体を表します。
ビュー・オブジェクト: 問合せコンポーネントを表します。
ビュー行: 指定された問合せコンポーネントの結果の各行を表します。
ビジネス・サービス実装におけるエンティティ・オブジェクトは、クライアントから直接参照されるように設計されていません。かわりに、クライアントは、アプリケーション・モジュールのデータ・モデルの一部として、ビュー・オブジェクトによる問合せデータを処理します。実際には、ビュー・オブジェクトはビジネス・サービス・レイヤー内のエンティティ・オブジェクトと自動的に連携し、ユーザーが変更したデータの検証と保存を調整します。この実行時の対話処理の詳細は、6.3.9項「実行時のビュー・オブジェクトとエンティティ・オブジェクトの連携処理」を参照してください。
oracle.jboパッケージのJavaインタフェースによって、クライアントがアクセス可能なビジネス・サービスに対するAPIが提供されます。このパッケージには、Entityインタフェース、またはクライアントがエンティティ・オブジェクトを直接操作できるようにするメソッドは含まれていません。かわりに、クライアント・コードが次のようにインタフェースと連携します。
ApplicationModule: アプリケーション・モジュールを処理します。
ViewObject: ビュー・オブジェクトを処理します。
Row: ビュー行を処理します。
クライアントからコール可能にするカスタム・コードをADF Business Componentsに追加する場合は、クライアントに表示されるコンポーネントすべてについて、その機能をクライアントに公開できます。JDeveloperでは、クライアント・インタフェース上で1つ以上のカスタム・メソッドをクライアントに公開している各コンポーネントに対して、関連するJavaインタフェース・ファイルが自動的に保持されます。そのため、Fusion Order Demoアプリケーションで使用されるStoreServiceAMなどのアプリケーション・モジュールで作業していると仮定すると、次のようなカスタム・インタフェースを利用できます。
カスタム・アプリケーション・モジュール・インタフェース
StoreServiceAM extends ApplicationModule
カスタム・ビュー・オブジェクト・インタフェース
OrderItemsInfo extends ViewObject
カスタム・ビュー行インタフェース
OrderItemsInfoRowClient extends Row
これにより、クライアント・コードでは、汎用クライアント・インタフェースをより詳細なインタフェースにキャストできます。詳細なインタフェースには、特定のコンポーネントに対して選択した、クライアントからアクセス可能な一連のメソッドが含まれます。
Groovyは、Javaプラットフォーム用のスクリプト言語で、Javaと同様の構文を持ちます。Groovyスクリプト言語では、ドット区切り表記法の採用により、コードの作成が簡素化されていますが、コレクション、文字列およびJavaBeansを操作する構文は引き続きサポートされています。強い型付け言語であるJavaがコンパイル時に実行されるのに対してGroovy式はランタイムに実行されるため、ADFビジネス・コンポーネントのGroovy言語式は、ビジネス・コンポーネント・カスタムJavaクラスで使用されるJavaコードとは異なります。また、Groovy式は動的にコンパイルされるため、式を使用するビジネス・コンポーネントのXML定義ファイル内に保存されます。
ADFビジネス・コンポーネントは、エンティティ・オブジェクトの属性やビュー・オブジェクトの属性へのアクセスが有用な場所でGroovyスクリプト言語の使用をサポートしており、これには属性バリデータ(エンティティ・オブジェクトの場合)、属性のデフォルト値(エンティティ・オブジェクトまたはビュー・オブジェクトの場合)、一時属性値の計算(エンティティ・オブジェクトまたはビュー・オブジェクトの場合)、バインド変数のデフォルト値(ビュー・オブジェクトの問合せ文およびビュー基準フィルタの場合)、およびエラー・メッセージのプレースホルダ(エンティティ・オブジェクトの検証ルールの場合)などが含まれます。さらに、ADFビジネス・コンポーネントには、Groovy式で使用できる組込みキーワードの限定されたセットが用意されています。
特にADF Business Componentsフレームワークでは、次のタスクを実行するためのGroovy言語式の使用に関するサポートが提供されています。
Script Expression ValidatorまたはCompare Validatorの定義(7.5項「検証とビジネス・ルールへのGroovy式の使用」を参照)
検証エラーを処理するエラー・メッセージ・トークンの定義(7.7.4項「エラー・メッセージにGroovy式を埋め込む方法」を参照)
バリデータの条件付き実行の処理(7.7.3項「Groovyを使用して条件付きでエラー・メッセージを呼び出す方法」を参照)
ビュー・オブジェクト問合せ文のバインド変数のデフォルト値の設定(5.10項「バインド変数の使用」を参照)
ビュー基準文の基準項目を指定するバインド変数のデフォルト値の設定(5.11項「名前付きビュー基準の処理」を参照)
エンティティ・オブジェク属性のデフォルト値およびオプションの再計算条件の定義(4.10.6項「静的なデフォルト値を定義する方法」を参照)
エンティティ・オブジェクトまたはビュー・オブジェクトの一時属性の値の算出(4.11項「エンティティ・オブジェクトへの一時属性および計算属性の追加」および5.14項「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照)
これらのタスクをJDeveloperで実行する場合、タスク固有の式エディタ・ダイアログを使用します。たとえば、一時ビュー・オブジェクト属性のデフォルト値を作成する場合、属性の「式エディタの編集」ダイアログを使用して、属性の実行時の値を決定する式を入力します。また、図3-9に示すように、同じダイアログで値をいつ計算するかも指定できます(再計算条件と呼ばれます)。
さらに、エンティティ・オブジェクトとビュー・オブジェクトを編集するために使用する概要エディタでは、「ビジネス・ルール」ページが表示され、単一のビジネス・コンポーネントで使用される式すべての表示と編集ができます。たとえば、ビュー・オブジェクト用に表示する「ビジネス・ルール」ページにより、ビュー・オブジェクトがそのビュー・アクセッサ、バインド変数および属性で使用する式すべてを表示できます。図3-10に示すように、表示をフィルタして、定義されたGroovy式でこれらの項目のみを表示できます。式はデザインタイム時に検証できませんが、すべての式エディタで、式の構文を保存する前にテストできます。
Groovy言語の詳細は、次のWebサイトを参照してください。
フレームワークでGroovyスクリプトを使用できるオブジェクトにアクセス可能な、adfという名前のトップレベルのオブジェクトが用意されています。Oracle ADFオブジェクトをGroovyスクリプト言語で参照する際、Oracle ADFランタイムではクラスの実際の具体的な型に対応しないラッパー・オブジェクトを戻します。これらのラッパー・オブジェクトでは、ラップされるオブジェクトのメソッドとフィールド型のすべてがサポートされています。あたかも実際のオブジェクトのように、式ではラッパー・オブジェクトを使用できます。ただし、ラッパー・オブジェクトを具体的な型にキャストしようとすると、ClassCastExceptionで失敗します。一般的に、Groovy言語で作業する際、明示的なキャストを使用する必要はなく、これらのラップされたADF Business Componentsオブジェクトの場合、これを行うと例外が発生します。
アクセス可能なOracle ADFオブジェクトの構成は次のとおりです。
adf.context: ADFContextオブジェクトを参照します。
adf.object: 式が適用されているオブジェクトを参照します(接頭辞adfを使用せずにキーワードobjectを使用して参照可能)。アクセス可能な他のメンバー名は、Groovyスクリプトが適用されたコンテキストに由来します。
エンティティ・オブジェクト属性: コンテキストはエンティティ実装クラスのインスタンスです。このオブジェクトを介して、カスタム・エンティティ実装クラスのカスタム・メソッドと、JavaDocのEntityImplに指定されたベース実装クラスで定義されているすべてのメソッドを参照できるほか、エンティティ・インスタンスの属性を参照できます。
エンティティ・オブジェクト・スクリプト検証規則: コンテキストは、バリデータが適用されるエンティティにマージされるバリデータ・オブジェクト(JboValidatorContext)です。このコンテキストで使用できるキーワードの詳細は、3.6.2.1項「同一のビジネス・コンポーネントのメンバーの参照」を参照してください。
ビュー・オブジェクト属性: コンテキストはビュー行実装クラスのインスタンスです。このオブジェクトを介して、カスタム・ビュー行実装クラスのカスタム・メソッドとJavaDocのViewRowImplに指定されたベース実装クラスで定義されているすべてのメソッドを参照できるほか、問合せ行セットで定義されているビュー行インスタンスの属性を参照できます。
ビュー・オブジェクトのバインド変数: コンテキストは、ビュー行ではなく変数オブジェクト自体です。structureDefプロパティを参照すると他の情報にアクセスでき、viewObjectプロパティを参照するとバインド変数を適用したビュー・オブジェクトにアクセスできます。ただし、ビュー・オブジェクト属性へのアクセスはサポートされていません。
ビュー・アクセッサのバインド変数: コンテキストは現在のビュー行です。バインド変数を使用するビュー・アクセッサは、カスケード値リスト(LOV)の作成に使用されます。ビュー・アクセッサは、有効な選択肢リストを編成するために使用されるビュー・アクセッサ・ビュー・オブジェクトの現在のビュー行からGroovyドリブン値を導出できます。
一時属性: コンテキストは現在のエンティティまたはビュー行です。属性が表示されるエンティティまたはビュー行の名前で属性を参照できるだけでなく、そのエンティティまたはビュー行のpublicメソッドも参照できます。現在のオブジェクトのメソッドにアクセスするには、objectキーワードを使用して現在のオブジェクトを参照する必要があります(例: object.methodName( ))。objectキーワードは、Javaのthisキーワードと同じです。一時式でこのキーワードを使用しないと、動的にコンパイルされたGroovyスクリプト・オブジェクト自体にメソッドが存在すると判断されます。
adf.error: 検証規則において、検証式で例外または警告を生成できるエラー・ハンドラにアクセスします。
adf.userSession - ADF Business Componentsユーザー・セッションへの参照を返します(セッションの一部であるuserDataハッシュマップの値の参照に使用できます)。
次の式を使用して現在の日付(時間を切捨て)または現在の日付と時間を参照することもできます。
adf.currentDate
adf.currentDateTime
Groovyスクリプト言語により、エンティティ・オブジェクトとビュー・オブジェクトのメソッドと属性へのアクセスのために記述するコードを容易に作成できます。
ビジネス・コンポーネントのメンバー(エンティティ・オブジェクトとビュー・オブジェクトで定義されるメソッドと属性を含む)の参照の最も単純な例は、式を適用する属性と同一のエンティティ・オブジェクトまたはビュー・オブジェクト内に存在する属性の参照です。
たとえば、従業員の月給を指定する属性Salを持つエンティティ・オブジェクトの一時属性AnnualSalaryの値を計算するGroovy式を定義できます。
Sal * 12
または、次のような構文を使用して、単一のビュー・オブジェクトの属性を比較する単純な検証規則をGroovyで作成できます。
PromotionDate > HireDate
Javaを使用すると、同じ比較は次のようになります。
((Date)getAttribute("PromotionDate")).compareTo((Date)getAttribute("HireDate")) > 0
現在のオブジェクトは、thisオブジェクトとしてスクリプトに渡されるため、属性名を使用するだけで現在のオブジェクトの属性を参照できます。たとえば、属性レベルまたはエンティティ・レベルのScript Expression Validatorで、HireDateという名前の属性を参照するには、スクリプトでHireDateを参照するだけですみます。
属性の参照と同様に、エンティティ実装クラスでカスタム・メソッドを定義する場合は、式の一部としてこれらのメソッドを起動できます。たとえば、次のように、属性のデフォルト値を定義します。
adf.object.getDefaultSalaryForGrade()
メソッド参照は接頭辞adf.objectを必要とし、これによって式が適用される属性を定義する同じエンティティを参照できます。これと同じ接頭辞を使用して、カスタム実装クラスが拡張するエンティティ実装クラス(EntityImpl.java)のベース・クラスのメソッドも参照できます。
検証規則でエンティティ実装クラスのメソッドを参照する場合は、接頭辞sourceを使用します。
source.getDefaultSalaryForGrade()
objectキーワードは、(メソッドが定義されている)エンティティ・オブジェクトではなく、検証規則オブジェクトを指すため、バリデータではsource接頭辞を使用する必要があります。
バリデータ・オブジェクトのメンバーを参照できるようにするために(JboValidatorContext)、検証ルール式で次のキーワードを使用できます。
newValue: 属性レベルのバリデータで、設定されている属性値にアクセスします。
oldValue: 属性レベルのバリデータで、設定されている現在の属性値にアクセスします。
たとえば、次の式を使用して、販売員の給与の動的検証ルール・チェックを指定できます。
if (Job == "SALESMAN")
{
return newValue < source.getMaxSalaryForGrade(Job)
}
else
return true
エンティティ・オブジェクトおよびビュー・オブジェクトで定義されているメソッドおよび属性を式で参照し、別のエンティティ・オブジェクトの属性または検証規則に適用することもできます。そのためには、エンティティ・アソシエーションのアクセッサを参照します。
たとえば、エンティティにDeptとEmpのマスター/ディテール・アソシエーションを定義する場合、デフォルトでエンティティ・アソシエーションのアクセッサにはDeptとEmpという名前が付けられ、関連元と関連先のデータ・ソースが指定されます。Groovy式でこのアクセッサを使用し、部門の場所に基づいて新しい従業員の給与のデフォルト値を設定します。
adf.object.getDefaultSalaryForGrade(Dept.Loc)
この式では、アソシエーションのアクセッサと同じ名前(Dept)であっても、エンティティを参照しません。そのかわりに、部門と従業員のマスター/ディテール関係を前提としてアクセッサを参照するため、従業員エンティティ・オブジェクトに対するGroovy式はマスターの部門エンティティを参照し、そのマスターからLoc値を渡します。
Oracle Business Components RowSetオブジェクトでは、次の組込みの集計関数を使用できます。
rowSetAttr.sum(GroovyExpr)
rowSetAttr.count(GroovyExpr)
rowSetAttr.avg(GroovyExpr)
rowSetAttr.min(GroovyExpr)
rowSetAttr.max(GroovyExpr)
これらの集計関数は、文字列値引数を使用し、これはGroovy式として解釈され、集計が計算される際に行セットの各行のコンテキストで評価されます。Groovy式は数値(または数字のドメイン)を返す必要があります。
たとえば、Deptエンティティ・オブジェクトには、次の式によって計算されるすべての従業員の給与の合計を表示する一時属性を追加できます。
EmployeesInDept.sum("Sal")
特定の部門の従業員を参照するために、式ではマスター/ディテール・アソシエーションの関連先Empエンティティのアクセッサ名を指定します。この場合、アクセッサはEmployeesInDeptで、給与はEmpエンティティ・オブジェクトのレコードごとに解釈されます。
または、各従業員の職務によって異なる福利厚生を含めて、特定の部門の給与合計を計算する場合には、次のようにします。
EmployeesInDept.sum("Sal + adf.object.getBenefitsValue(Job)")
