Oracle Fusion Middleware Oracle Application Development Framework Fusion開発者ガイド 11gリリース1 (11.1.1.7.0) B52028-05 |
|
前 |
次 |
この章ではOracle Application Development Framework (Oracle ADF)のADFビジネス・コンポーネント・レイヤーで作業を開始する際に使用できる主要な機能について説明します。また、ADFビジネス・コンポーネントの実装アーキテクチャについて説明し、エンティティ・オブジェクトとビュー・オブジェクトでGroovyスクリプト言語に関するサポートについても説明します。
この章の内容は次のとおりです。
ADFビジネス・コンポーネントおよびJDeveloperを使用すると、Java EEプラットフォームのビジネス・アプリケーションを容易に開発、提供およびカスタマイズできます。開発者は、ADFビジネス・コンポーネントを使用して次の作業を行う場合、通常のJava EEアプリケーションに必要なアプリケーションのインフラストラクチャ・コードを記述する必要はありません。
データベースへの接続
データの取得
データベース・レコードのロック
トランザクションの管理
ADFビジネス・コンポーネントは、再利用可能なソフトウェア・コンポーネントのライブラリおよびJDeveloperの設計時機能のサポートを介してこれらのタスクを処理します。最も重要な点は、JDeveloperでの設計時に一般的な開発タスクを全体的に宣言的にするため、開発者はADFビジネス・コンポーネントを使用して時間を節約できることです。特に、JDeveloperではADFビジネス・コンポーネントによる宣言的開発をサポートし、次のタスクを行います。
自動的にデータベースと統合するコンポーネント内のビジネス・ロジックの、記述およびテスト
複数のアプリケーションタスクをサポートする、データの複数のSQLベースのビューを介したビジネス・ロジックの再使用
ブラウザ、デスクトップ、モバイル、Webサービス・クライアントからの、ビューへのアクセスおよび更新
配布したアプリケーションの修正を必要としないレイヤー単位のアプリケーション機能のカスタマイズ
ADFビジネス・コンポーネントの目的は、ビジネス・サービス開発者の生産性をより高めることです。
ADFビジネス・コンポーネントは、次の領域で提供される機能をビジネス階層アプリケーション・コンポーネントによって活用できる、Javaクラスの基盤を提供します。
必要なデータのみをクライアントに表示するデータ・モデルの設計
データ・モデルの一部としての複雑なマスター/ディテール階層の組込み
コード記述を必要としない、エンド・ユーザーのQuery-By-Exampleデータ・フィルタの実装
データ・モデル変更のビジネス・ドメイン・オブジェクト・レイヤーとの自動調整
データベースに対する変更の自動検証および保存
必須フィールド、主キーの一意性、データの精度と規模および外部キー参照の宣言的な実行
マルチレベルでの検証サポートを含めた、プログラムまたは宣言による、簡単なビジネス・ルールと高度なビジネス・ルール両方の簡単な取得および実行
ビジネス・ドメイン・オブジェクト間の関係のナビゲートおよび複合コンポーネント関連の制約の実行
ビジネス・サービス・アプリケーション・ロジックによるユーザー・インタフェースにおける変更の自動反映
関連する表からの参照情報の取得と、ユーザーによる外部キー値の変更時の自動保持
Web階層の自動的な状態管理による、複数ステップのWebベース・ビジネス・トランザクションの簡略化
コードを必要としない、イメージ、ビデオ、音声およびドキュメントの処理
データの複数ビューにおける、保留中のデータ変更の同期化
複数アプリケーションにおける、プロンプト、ツールチップ、フォーマット・マスク、エラー・メッセージの一環した適用
メタデータ駆動型ユーザー・インタフェースまたはアプリケーション機能をサポートする、ビジネス・コンポーネントに対するカスタム・メタデータの定義
行単位の状態管理を簡略化する動的属性の、実行時の追加
コードを記述せずにビジネス統合できる高機能Webサービス・インタフェースのサポート
ベスト・プラクティスであるインタフェース・ベースのプログラミング・スタイルの適用
自動JAAS統合および監査メンテナンスによるアプリケーション・セキュリティの簡略化
「一度記述すれば、どこでも実行可能」: プレーンなJavaクラスまたはWebサービスと同様のビジネス・サービスの使用
ソース・コードの変更を必要としない、提供後のコンポーネント機能の拡張
アプリケーションの修正を必要としない、提供済コンポーネントの拡張版へのグローバルな代替
カスタマイズが失われない、または下方カスタマイズの手動での再適用を必要としない、アプリケーション・アップグレードの提供
ADFビジネス・コンポーネントは、次のコンポーネントと連携してビジネス・サービスを実装します。
エンティティ・オブジェクト
エンティティ・オブジェクトは、データベース表内の1行を表し、すべてのデータ操作言語(DML)操作を処理することでデータ変更を簡略化します。また、該当する行のビジネス・ロジックをカプセル化し、ビジネス・ルールが一貫して適用されることを保証します。エンティティ・オブジェクトを他のエンティティ・オブジェクトと関連付け、基盤となるデータベース・スキーマの関係を反映することで、複数のアプリケーションで再使用できるビジネス・ドメイン・オブジェクトのレイヤーを作成します。
ビュー・オブジェクト
ビュー・オブジェクトは、SQL問合せを表します。使い慣れたSQL言語を十分に活用し、エンド・ユーザーのタスクが必要とする形に、データを正確に結合、フィルタ、ソートおよび集約します。これには、ビュー・オブジェクトを他のビュー・オブジェクトにリンクし、複雑度にかかわらずマスター/ディテール階層を作成する機能も含まれます。エンド・ユーザーがユーザー・インタフェースを使用してデータを変更すると、ビュー・オブジェクトはエンティティ・オブジェクトと連携し、変更内容が一貫して検証され、保存されます。
アプリケーション・モジュール
アプリケーション・モジュールは、UIクライアントがアプリケーション・データの操作に使用するトランザクション・コンポーネントです。これによって、エンド・ユーザー・タスクに関連した作業論理ユニットに関連する、更新可能なデータ・モデルやトップレベルのプロシージャおよびファンクション(サービス・メソッド)を定義します。
ベース・コンポーネントは、組込み動作によってすべての一般的なケースを処理しますが、カスタマイズはいつでも可能であり、ベース・コンポーネントで提供されるデフォルトの動作を簡単に上書きまたは補強できます。
ADFビジネス・コンポーネントでは、エンタープライズ4GLツールと類似した機能を実装するコンポーネントを提供しています。ADFビジネス・コンポーネントでは、複数の主要コンポーネントを、他の4GLツールで精通している概念上に位置付けています。
ADFビジネス・コンポーネントは、ユーザー・インタフェースに依存しない方法で、使い慣れた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 ADFでは、一般的なForms機能を実装し、すぐに使用できるJavaコンポーネントを提供することで、前述のUI/データ分割を実現します。問合せとエンティティ関連で機能の役割が明確に区別され、より適切に再利用できます。
アプリケーション・モジュール・コンポーネントは、フォームのデータ部分です。アプリケーション・モジュールは、クライアント・インタフェースで処理が必要なマスター/ディテール関連の問合せに関するデータ・モデルを含む、スマート・データ・サービスです。また、これに含まれるコンポーネントで使用されるトランザクションとデータベース接続を提供します。このコンポーネントには、サービス実装においてカプセル化される、サービス・メソッドと呼ばれるフォーム・レベルのプロシージャおよびファンクションが含まれています。このプロシージャやファンクションのうち、どれをプライベートに設定し、どれをパブリックに設定するかを決定できます。
エンティティ・オブジェクト・コンポーネントは、前述のデータ・ブロック機能のうち、検証およびデータベース変更に関する部分を実装します。Formsの実行時には、この処理はレコード・マネージャによって実行されます。レコード・マネージャは、適切なタイミングでのブロック・レベルやアイテム・レベルでの検証トリガーの実行、およびデータベースへの変更の格納に関する調整を行うため、データ・ブロックのどの行が変更されたかを追跡します。この処理は、まさにエンティティ・オブジェクトが実行するものです。エンティティ・オブジェクトとは、基礎となるデータベース表によってビジネス・ドメインのエンティティを表すコンポーネントです。エンティティ・オブジェクトでは、ビジネス・オブジェクトの検証、デフォルト設定、データベース変更処理に関連するビジネス・ロジックをカプセル化するための場所を提供します。
ViewObject
コンポーネントは、データ・ブロック機能のうち、データの取得を実行します。各ビュー・オブジェクトではSQL問合せをカプセル化し、実行時にはそれぞれの問合せ結果セットを管理します。マスター/ディテール関連で2つ以上のビュー・オブジェクトを接続する場合、その調整は自動的に処理されます。ビュー・オブジェクトを定義する際、すべての問合せ列を、基礎となるエンティティ・オブジェクトにリンクさせることができます。この情報を取得することにより、ビュー・オブジェクトとエンティティ・オブジェクトは実行時に自動的に連携し、ユーザーのタスクで必要となるビジネス・データの形態にかかわらず、ドメインのビジネス・ロジックを実行します。
PeopleToolsを使用したソリューションの開発経験者は、PeopleToolsコンポーネントの構造をよく理解しています。ADFビジネス・コンポーネントには、PeopleToolsで使い慣れているデータ・アクセス機能が実装されています。
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ビジネス・コンポーネントに実装されていることがわかります。
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で使い慣れているすべてのデータ・アクセス機能が、様々な拡張機能とともに実装されています。
アプリケーション・モジュール・コンポーネントは、ADO.NETデータセットと同じ役割を果します。これは、ビュー・オブジェクト・インスタンスと呼ばれる行セットのコレクションを表す、強く型付けされたサービス・コンポーネントで、ADO.NETデータ表と類似しています。アプリケーション・モジュールによって、開発者による構成が可能な一連のビュー・インスタンスのデータの行を表すサービス・インタフェースが、SDOと互換性のあるサービス(Webサービス、またはSCAコンポジットとしてアクセス可能)として公開されます。アプリケーション・モジュールは、関連するトランザクション・オブジェクトと連携し、ビュー・オブジェクトが実行するSQL問合せのコンテキストを提供します。また、アプリケーション・モジュールは、ADO.NETデータ・アダプタの役割を果す、エンティティ・オブジェクトによってデータベースに保存された変更のコンテキストを提供します。
エンティティ・オブジェクト・コンポーネントは、強く型付けされたADO.NETデータ・アダプタと同様のものです。これは特定の表における行を表し、その行の主キーによる検索、挿入、更新、削除およびロックの操作を処理します。ADFビジネス・コンポーネントでは、これらの文を自分で記述する必要はありませんが、必要に応じて上書きできます。エンティティ・オブジェクトは、属性や基礎となる表の行全体に関連する、検証や他のビジネス・ロジックをカプセル化します。検証は、エンド・ユーザーが基礎となるエンティティ・オブジェクトを参照するすべてのビュー・オブジェクト問合せを使用してデータを更新および保存したときに実行されます。ADFビジネス・コンポーネントの相違点としては、任意の柔軟な問合せがSQL文によってビュー・オブジェクト・インスタンス・レベルで実行されますが、ビュー・オブジェクトとエンティティ・オブジェクトが実行時に自動的に連携するという点があります。
ビュー・オブジェクト・コンポーネントは、SQL問合せをカプセル化し、結果となる行セットを管理します。基礎となるエンティティ・オブジェクトと関連付けることにより、ユーザーによるそれらの行の検証や変更の保存を自動的に調整します。ビュー・オブジェクトの問合せデータと、エンティティ・オブジェクトのカプセル化されたビジネス・ロジックの連携により、データ表のすべての利点に加え、ビジネス・ドメイン・オブジェクトのレイヤーに対するビジネス・ロジックの明確なカプセル化が可能になります。ADO.NETデータ表のように、ビュー・オブジェクトのデータをXMLとして簡単に扱うこと、およびビュー・オブジェクトでXMLデータを読み込み、その情報に基づいた行の挿入、更新または削除などを自動的に行うことができます。
JDeveloperは、ADFビジネス・コンポーネントに対する包括的な設計時サポートを提供します。これらの機能では、ビジネス・コンポーネントの作成、編集、ダイアグラム表示、テストおよびリファクタを一括して実行できます。
最初にコンポーネントを作成する場合は、図3-1に示すように、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログが表示されます。このダイアログでは、このデータ・モデル・プロジェクトのビジネス・コンポーネントで作業する際に使用する、設計時のアプリケーション・リソース接続を選択したり、既存のIDEレベルの接続をコピーして新規のアプリケーション・リソース接続を作成します。
このダイアログは最初のビジネス・コンポーネントを作成する前に表示されるため、これを使用して、ビュー・オブジェクトがSQL文を策定するために使用するSQLプラットフォームをグローバルに制御します。選択できるSQLプラットフォームは次のとおりです。
Oracleデータベース接続用のOracle SQLプラットフォーム(デフォルト)
Oracle Liteデータベース用のOLite
Microsoft SQL Serverデータベース用のSQLServer
IBM DB2データベース用のDB2
その他のサポートされるSQL92準拠のデータベース用のSQL92
注意: OracleデータベースとOracle以外のデータベースの両方に対してアプリケーションを実行する予定がある場合、後ではなくアプリケーションを構築し始める際に、SQL92 SQLプラットフォームを選択する必要があります。これにより、Oracle SQLプラットフォームを使用する場合に特有の、Oracle固有の最適化機能の一部は使用できなくなりますが、OracleデータベースとOracle以外のデータベースの両方に適用できるアプリケーションを構築できます。 |
このダイアログでは、データ・モデル・プロジェクトで使用するデータ型のセットも決定できます。JDeveloperはデータ型の選択を使用して、データ・モデル・プロジェクト内でエンティティ・オブジェクトおよびビュー・オブジェクトを作成する際に使用される属性のデータ型を定義します。したがって、「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログで設定を保存する前に適切な選択を行うことが重要です。このダイアログには、次のオプションがあります。
JDeveloperによりOracleデータベース・ドライバを使用していることが検出されると、「Oracle用拡張Java」型マップがデフォルトで選択されます。「Oracle用拡張Java」型マップでは、一般的なデータ型として、標準Java型およびoracle.jbo.domain
パッケージに含まれる最適化されたデータ型を使用します。
ヒント: 新しいFusion Webアプリケーションでは、デフォルトの「Oracle用拡張Java」型を使用する必要があります。 |
「Java」型マップは、Oracle以外のデータベース上で実行され、SQL92準拠を使用して作成するアプリケーションをサポートするために提供されています。この場合、基本のJavaデータ型のみをグローバルに使用するように、データ型マップを「Java」に設定します。
「Oracleドメイン」型マップは、3.3.2項「数値の表示について」で説明しているように、後方互換性、およびビュー・レイヤー・テクノロジとしてADF Facesを使用しないADFアプリケーション用に提供されています。JDeveloperリリース11.1.1.4.0以前で開発されたアプリケーションを移行する際、アプリケーションでは引き続き「Oracleドメイン」型マップが使用され、現在のデフォルト型マップの「Oracle用拡張Java」に変更されません。
「ビジネス・コンポーネント・プロジェクトの初期化」ダイアログでプロジェクトの選択を保存すると、プロジェクトは初期化されたとみなされ、データ型マップの選択を変更することはできなくなります。プロジェクトを初期化したら、adf-config.xml
ファイルに対する概要エディタの「ビジネス・コンポーネント」ページでSQLプラットフォームをオーバーライドできますが、これはプロジェクトにビジネス・コンポーネントを追加する前に行う必要があります。adf-config.xml
ファイルは、「アプリケーション・リソース」ペインで「ディスクリプタ」→「ADF META-INF」ノードを開くと表示されます。adf-config.xml
ファイルでデータ型を指定することにより、デプロイ済のFusion Webアプリケーションの実際のデータベース型を必要とするSQL文を実行時に生成することがサポートされます。
「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コンポーネントのないアプリケーションは問題なく機能します。
「新規ギャラリ」の「ADFビジネス・コンポーネント」カテゴリでは、JDeveloperはそれぞれのビジネス・コンポーネントを作成するためのウィザードを提供しています。各ウィザードでは、新規コンポーネントのコンポーネント名を指定し、どのパッケージにコンポーネントを配置するかを選択できます。パッケージがまだ存在しない場合、新規コンポーネントがそのパッケージの最初のコンポーネントになります。
ウィザードには、コンポーネント・タイプを作成するために必要な情報を収集する、一連のパネルが表示されます。「終了」をクリックすると、XMLコンポーネント定義ファイルが保存され、新規コンポーネントが作成されます。デフォルトでクラス生成にJava生成オプションを設定している場合、JDeveloperでは初期のカスタムJavaクラス・ファイルも同時に作成されます。
アプリケーション・ナビゲータ内にパッケージを含めた後は、アプリケーション・ナビゲータからパッケージを選択し、図3-2に示すポップアップ・メニューからオプションを選択することで、追加の各種ビジネス・コンポーネントを迅速に作成できるようになります。
ビジネス・コンポーネントが作成された後は、「アプリケーション」ウィンドウでコンポーネントをダブルクリックするか、コンポーネントを選択し、ポップアップ・メニューから「開く」オプションを選択することにより、対応する概要エディタを使用してそのプロパティを編集することができます。
概要エディタには、ウィザードに表示されるのと同じ編集オプションが表示されますが、表示項目の配置が異なる場合があります。概要エディタでは、コンポーネントのすべての特徴を変更できます。コンポーネントのエディタで変更を加えると、コンポーネントのXMLコンポーネント定義ファイルが更新され、関連するすべてのカスタムJavaファイルが必要に応じて更新されます。概要エディタは、モーダル・ダイアログではなくJDeveloperの編集ウィンドウであるため、必要な数のコンポーネントの概要エディタを開いて表示できます。
JDeveloperでは、ADFビジネス・コンポーネントに対する充実したUMLダイアグラム・サポートが提供されます。作成済の既存のコンポーネントは、ビジネス・コンポーネント・ダイアグラムに追加して視覚化できます。また、コンポーネントの作成および変更にダイアグラムを使用することもできます。ダイアグラムは、エディタでの変更と同期しています。
新しいビジネス・コンポーネント・ダイアグラムを作成するには、JDeveloperの「新規ギャラリ」の「ADFビジネス・コンポーネント」カテゴリから、「ビジネス・コンポーネント・ダイアグラム」アイテムを使用します。このカテゴリは、Business Tierの選択肢の一部です。
アプリケーション・モジュール・コンポーネントの作成後は、組込みのビジネス・コンポーネント・ブラウザを使用し、繰り返しテストできます。ビジネス・コンポーネント・ブラウザを実行するには、アプリケーション・ナビゲータまたはビジネス・コンポーネント・ダイアグラムでアプリケーション・モジュールを選択し、ポップアップ・メニューから「実行」または「デバッグ」を選択します。
ビジネス・コンポーネント・ブラウザではアプリケーション・モジュールのデータ・モデルにビュー・オブジェクト・インスタンスを提供し、動的に生成されるユーザー・インタフェースを使用してユーザーとインスタンスとの対話を可能にします。このツールでは、アプリケーション・モジュールのクライアント・インタフェース・メソッドのリストも提供され、アプリケーション・モジュールのノードをダブルクリックすると、対話的にテストできます。このツールは、Webページのビュー・レイヤー作成の前後において、ビジネス・サービスのテストやデバッグに必要不可欠なものです。
「アプリケーション・ナビゲータ」でコンポーネントを選択し、ポップアップ・メニューから「リファクタ」→「名前の変更」を選択すると、いつでもコンポーネントの名前を変更できます。構造ウィンドウには、アプリケーション・モジュール・データ・モデルのビュー・オブジェクト属性やビュー・インスタンスなど、アプリケーション・ナビゲータには表示されないコンポーネントの詳細のための「名前の変更」ポップアップ・メニュー・オプションも表示されます。また、ナビゲータ内で[Ctrl]キーを押しながらクリックして1つ以上のコンポーネントを選択し、次にポップアップ・メニューから「リファクタ」→「移動」を選択すると、選択したコンポーネントを新規パッケージに移動できます。現在のデータ・モデル・プロジェクト内の古いコンポーネント名やパッケージへの参照は、自動的に修正されます。
ビジネス・サービスの実装における、ADFビジネス・コンポーネントを使用した簡略化の主要な利点の1つは、アプリケーション・モジュールが行セットのUI対応データ・モデルをサポートしている点です。各ビジネス・オブジェクトの行セットにはデータが含まれていますが、データ・モデルはアプリケーション固有のビジネス・オブジェクトを定義します。アプリケーションのUI部分において、UIコンポーネントはビジネス・オブジェクトと対話し、取得、作成、編集および削除の操作を実行します。ADFモデル・レイヤーとADF Faces UIコンポーネントを組み合せてADFビジネス・コンポーネントを使用する場合、UIコンポーネントは自動的に更新してビジネス・オブジェクトの行セットに対する変更を反映するため、データ・モデルはUI対応になります。
このように、UI対応データ・モデルは、UIとデータ・モデルが常に同期するよう、アプリケーション・テクノロジ・レイヤー全体に渡って動作するソリューションを表します。
一般的なJava EEビジネス・サービスの実装を使用する場合、クライアントの開発者は次の点に留意する必要があります。
データを再表示するため、サービス・メソッドを起動します。
クライアントがどのデータを作成、削除、変更したかを追跡します。
変更を検証および保存するため、変更を1つ以上の異なるサービス・メソッドに渡します。
取得、作成、編集、削除および保存は、アプリケーション開発で実行される一般的な一連のタスクです。結果として、ADFアプリケーション・モジュールは、より高度で汎用的なソリューションを示します。ビジネス・サービスでアプリケーション・モジュールを使用すると、フィールド、表、ツリーなどのクライアントUIコンポーネントを、アプリケーション・モジュールのデータ・モデルにおけるアクティブ・ビュー・オブジェクト・インスタンスにバインドするのみですみます。Webやモバイル・デバイス用のJSPまたはJSFページのUIコンポーネント(Swingを使用した、ウィンドウやパネルから構成されるデスクトップ・フィデリティのUIも含む)は、データ・モデルのビュー・オブジェクト行セットの行に対する変更を反映するよう自動的に更新されます。このアクティブなデータ通知は、データ・モデルへの変更を行うカスタム・ビジネス・サービス・メソッドにもおよびます。
アプリケーション・モジュール・コンポーネントは一連の汎用サービス・メソッドを実装するため、ユーザーは、サービス指向アーキテクチャ(SOA)でUI対応データ・モデルを活用できるようになります。WebサービスおよびUIクライアントは、単純なAPIを使用してアプリケーション・モジュールのデータ・モデルに容易にアクセスできます。これらのAPIにより、アプリケーション・モジュールで利用可能な任意の情報を検索および修正できます。
宣言的なデータバインドのためのADFモデル・レイヤーを活用するUIを構築する場合、一般的に、クライアント側のコードを記述する必要はありません。データ・モデルはUI対応のため、UIコンポーネントは、データ・モデルのビュー・オブジェクトおよびカスタム・ビジネス・サービス・メソッドに宣言的にバインドされます。
UI対応データ・モデルがない場合、日常的に使用する単純なCRUDスタイルの操作を処理するには、クライアント側でより多くのコードを記述する必要があります。さらに、ページを常に最新に保つために「リフレッシュ・フラグ」を管理し、変更された可能性のあるデータを反映するためのビジネス・サービスからのデータ再取得リクエストをコントロール・レイヤーに通知する必要があります。ADFアプリケーション・モジュールを使用してビジネス・サービスを実装する場合、エンド・ユーザーの期待どおりに業務を処理するための調査を行うかわりに、ビジネス・ロジックに焦点を当てることができます。
UI対応データ・モデルの、次の3つの具体的な例について検討します。
新規データの対応する画面への、再問合せなしの表示
顧客がFusion Order Demoアプリケーションにログインすると、ショッピング・カートの項目のリストが表示されます。次に製品ページから発注項目を新たに作成し、ショッピング・カートに戻ると、アプリケーションでデータベースに再問合せしなくても、新規項目がリスト内に表示されます。
ビジネス・ドメイン・ロジックによる変更の自動反映
バック・オフィス・アプリケーションによって、発注状況が更新されます。ビジネス・ドメイン・レイヤーのOrders
エンティティ・オブジェクトにカプセル化されたビジネス・ロジックには、発注状況の属性に変更があった場合は常に最新更新日を更新する簡単なルールが含まれています。ユーザー・インタフェースは、ビジネス・ドメイン・レイヤーのロジックが変更された最新更新日を自動的に反映するよう更新されます。
ビジネス・サービス・メソッドのデータの再問合せと現在行の設定の実行
ツリー表示で、ユーザーがツリー内のあるノードをクリックします。この操作により、アプリケーション・モジュール内のビジネス・サービス・メソッドが宣言的に起動され、マスター/ディテール情報を再問合せし、現在行を行セットの適切な行に設定します。画面は新規マスター/ディテール・データと現在行の表示を反映するよう更新されます。
アプリケーション・モジュールはUI対応データ・モデルをサポートしているため、クライアント・ユーザー・インタフェースは常に最新に保たれます。つまり、データ・モデルの設定または操作に関連するクライアント側のコードを記述する必要がありません。
ADFビジネス・コンポーネントの使用によって記述が不要になるクライアント側コードの一般的な型としては、他に、マスターの行が変更された場合の詳細データ・コレクションを調整するコードがあります。ビュー・オブジェクトをリンクすることにより、この調整は自動的に実行されます。
ただし、カスタム・コードを記述する必要がある場合は、アプリケーション・モジュール・コンポーネントのカスタム・メソッド内でこのコードをカプセル化してください。たとえば、ビュー・オブジェクトを操作するプログラム的なコードが完全なビジネス・サービス機能を実装するための論理的な特徴を備えている場合、アプリケーション・モジュールのJavaクラスでカスタム・メソッドを記述して、詳細をカプセル化する必要があります。これには次のコードが考えられますが、これらのコードに限定されるものではありません。
表示するデータを正しく問い合せるためのビュー・オブジェクト・プロパティの構成
集計結果を取得するための、ビュー・オブジェクト行の反復処理
1つ以上のビュー・オブジェクトに対する、複数ステップのプロシージャによるロジックの実行
これらの実装の詳細をアプリケーション・モジュール内で一元管理することで、次の利点が得られます。
コードの目的が、クライアントにより明確に伝わります。
必要に応じて、複数のクライアント・ページから同じコードを簡単にコールできます。
ビジネス・サービス機能全体の回帰テストを簡略化できます。
クライアントに影響を与えることなく、実装を改善するオプションを使用可能にできます。
ページ内での論理的ビジネス機能の宣言的起動が可能になります。
特定のADFビジネス・コンポーネントの実装を開始する前に、Oracle ADFビジネス・サービス・レイヤーの設計および実装に関してよく理解しておくことをお薦めします。
ADFビジネス・コンポーネントは、Oracle ADFのすべてのテクノロジと同様、Javaで実装されています。コンポーネントはフレームワーク内で動作し、テストされ、堅牢なコードの豊富なレイヤーから汎用性の高いメタデータ駆動型の機能を提供します。ADFビジネス・コンポーネントは、Java EEコミュニティのベスト・プラクティスに準拠しており、明確に分離されたXMLファイル内に各コンポーネントの実行時の動作を構成するために定義したメタデータが保持されています。
ADFビジネス・コンポーネントはビジネス上非常に重要なアプリケーションにおいて使用されることが多いため、サポート契約を締結しているお客様は、ADFビジネス・コンポーネント・レイヤーを含むOracle ADFの完全なソースをOracle Worldwide Supportから入手できます。31.7項「ADF宣言デバッガの使用」で説明されているように、Oracle ADFの完全なソースコードは、問題の診断に役立つ重要なツールです。37.2項「拡張クラスによるフレームワークの動作のカスタマイズ」で説明されているように、Oracle ADFの完全なソース・コードを使用すると、必要に応じてベース・フレームワーク機能を適切に拡張する方法を理解するためにも役立ちます。
ADFビジネス・コンポーネントを使用して構築されたアプリケーションは、Java EE準拠のアプリケーション・サーバーを含む、Java対応のすべてのアプリケーション・サーバーで実行可能です。ビジネス・コンポーネントは、プレーンなJavaクラスとXMLファイルを使用して実装されているため、Java仮装マシンが存在するすべての実行環境で使用可能です。つまり、ADFビジネス・コンポーネントを使用して構築されたサービスは、実行時にアプリケーションのコンテナと呼ばれるJava EEサーバーの内部と、サーバーの外部の両方で簡単に使用できます。
顧客は、コマンドラインのバッチ・プログラム、Webサービス、カスタム・サーブレット、JSPページ、Swingによって構築したデスクトップ・フィデリティ・クライアントなど、様々な構成でアプリケーション・モジュールを日常的に使用します。
3.3.1項「接続、SQLスタイルおよび型マップの選択」で説明されているように、Oracle以外のデータベースと連携するアプリケーションを構築することもできます。ただし、Oracleデータベースを対象とするアプリケーションでは、ADFビジネス・コンポーネントに対して様々な最適化が構築されています。
ADFビジネス・コンポーネント・レイヤーは、実際のエンタープライズJava EEアプリケーション作成のために理解、実装およびデバッグする必要のある、一般的なすべてのJava EEデザイン・パターンを実装しています。ADFビジネス・コンポーネント・デザイン・パターンにおけるJava EE仕様のこれらのデザイン・パターンの名称のクロス・リファレンスが必要な場合は、付録F「ADFビジネス・コンポーネントJava EEデザイン・パターン・カタログ」を参照してください。
ADFビジネス・コンポーネントはJavaで実装されているため、クラスおよびインタフェースはパッケージ化されています。Javaパッケージは、ピリオドで区切った名前で識別され、開発者は階層型のネーミング構造でコードを整理できます。
ADFビジネス・コンポーネントにより提供されたソース・コードを構成するクラスおよびインタフェースは、oracle.jbo
パッケージおよび多数のサブパッケージに含まれます。ただし、ADFビジネス・コンポーネントを使用した日常作業においては、主に次の2つの主要パッケージに含まれるクラスやインタフェースを使用します。
ビジネス・サービス・クライアントの連携のために設計されたすべてのインタフェースが含まれる、oracle.jbo
パッケージ
これらのインタフェースを実装するクラスが含まれるoracle.jbo.server
パッケージ
注意: ここでのクライアントという用語は、ビジネス・サービスとしてアプリケーション・モジュール・コンポーネントにアクセスするモデル・レイヤー、ビュー・レイヤーまたはコントローラ・レイヤー内のコードを意味します。 |
図3-3に、アプリケーション・モジュール・コンポーネントの具体的な例を示します。アプリケーション・モジュールのためのクライアント・インタフェースは、oracle.jbo
パッケージの中のApplicationModule
インタフェースです。このインタフェースは、クライアントがアプリケーション・モジュールとの連携に利用可能なメソッドの名前やシグネチャを定義しますが、その機能の実装の仕様は含まれていません。アプリケーション・モジュール・コンポーネントのベースとなる機能を実装するクラスは、oracle.jbo.server
パッケージに含まれているApplicationModuleImpl
というクラスです。
ADFビジネス・コンポーネントはJavaで実装されているため、クラス、インタフェース、およびメタデータ・ファイルなどアプリケーションのコンポーネントもパッケージ化されます。
コンポーネントが他の組織の再使用可能なコンポーネントと競合しないように、パッケージ名の先頭に組織名またはWebドメイン名を付けます。たとえば、Apacheでは、Tomcat Webサーバーと関連付けるためにパッケージ名としてorg.apache.tomcat
を指定しており、Oracleでは、XML Parserのパッケージ名としてoracle.xml.parser
を指定しています。自社アプリケーション用に作成したコンポーネントは、com.
yourcompany
.
yourapp
などの名前でパッケージおよびそのサブパッケージに配置されます。
具体的な例として、Fusion Order Demoアプリケーションの主要なビジネス・サービスを構成するADFビジネス・コンポーネントは、oracle.fodemo.storefront
パッケージおよびサブパッケージに配置されています。図3-4に示すように、これらのコンポーネントは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つのパッケージまとめる構造と各コンポーネントを個々のパッケージに分ける構造)のどこかに収まることがわかります。
ADFビジネス・コンポーネントのパッケージは、他のデータ・モデル・プロジェクトでの再使用のためにJDeveloperがサポートする最小レベルの単位であることを考慮に入れる必要があります。そのため、コンポーネントをどのように配置するかを考慮する場合もあります。詳細は、37.6項「再利用可能なビジネス・コンポーネントのライブラリでの作業」を参照してください。
ADFビジネス・コンポーネントの各コンポーネントには、宣言的な設定によって制御される、組込みランタイム機能が付属しています。これらの設定は、コンポーネントと同じ名前のXMLコンポーネント定義ファイルに格納されています。コンポーネントの動作を拡張するなど、コンポーネントのカスタム・コードを記述する必要がある場合、該当するコンポーネントに対するオプションのカスタムJavaクラスを有効にできます。図3-5は、アプリケーション・モジュールに対するXMLコンポーネント定義およびオプションのカスタムJavaクラスがアプリケーション・ナビゲータでどのように表示されるかを示しています。
図3-6は、com.
yourcompany.yourapp
パッケージ内で作成した、アプリケーション・モジュールYourService
などのアプリケーション固有のコンポーネントに対するXMLコンポーネント定義ファイルを示しています。対応するXMLコンポーネント定義は、データ・モデル・プロジェクトのソース・パスのルート・ディレクトリ内のサブディレクトリ./com/
yourcompany/yourapp
に保存されます。そのXMLファイルには、実行時にアプリケーション・モジュール実装を提供するJavaクラスの名前が記録されます。この場合、XMLにはOracle ADFが提供するoracle.jbo.server.ApplicationModuleImpl
ベース・クラスの名前が記録されます。
カスタマイズを行わずに使用した場合、コンポーネントは、XMLコンポーネント定義で完全に定義されており、コンポーネントのカスタムJavaコードやJavaクラス・ファイルをまったく必要とせず、十分な機能を備えています。ADFビジネス・コンポーネントのコンポーネントの組込み機能を拡張する必要がない場合、また、組込みイベントを処理するカスタム・コードを記述する必要がない場合、このXMLのみの方法でコンポーネントを使用できます。
コンポーネントのベース機能を拡張するため、またはイベントを処理するためにカスタム・コードを追加する必要がある場合、作成するADFビジネス・コンポーネントのすべての主要タイプに対し、カスタムJavaクラスを有効にできます。コンポーネントのカスタム・クラスの生成は、JDeveloperの対応する概要エディタの「Java」ページで有効にします。このオプションを有効にすると、JDeveloperにより、構成可能な命名の標準に準拠したコンポーネントに関連するカスタム・クラスのJavaソース・ファイルが作成されます。このクラスの名前は、コンポーネントのXMLコンポーネント定義に記録され、コンポーネントで必要とされるカスタムJavaコードは、このクラス内に記述できます。コンポーネントに対してカスタムJavaクラスを有効にすると、コンポーネントの「アプリケーション・ナビゲータ」のポップアップ・メニューから、対応する「componentNameクラスに移動」オプションを使用してそこにナビゲートできます。
図3-7は、YourService
アプリケーション・モジュールに対してカスタムJavaクラスを有効にするとどうなるかを示しています。YourServiceImpl
.java
ソース・コード・ファイルが、コンポーネントのXMLコンポーネント定義ファイルと同じソース・パスの同じディレクトリに作成されます。YourServiceImpl
.xml
ファイルでは、ApplicationModuleImpl
クラスではなく、com.
yourcompany.yourapp.YourServiceImpl
ベース・クラスを実行時に使用するよう、変更が反映されます。
注意: このガイドの例では、生成済のカスタム・コンポーネント・クラスやインタフェースの名前には、デフォルトの設定を使用しています。自社アプリケーションでこれらのデフォルトを変更するには、JDeveloperの「設定」ダイアログの「ビジネス・コンポーネント: クラス・ネーミング」ページを使用してください。ここでの変更は、新しく作成したコンポーネントにのみ反映されます。 |
Java言語は文字列、日付、数値などのデータを処理するため、数多くの組込みデータ型を備えています。ADFビジネス・コンポーネントにおいても、これらの型を使用可能ですが、デフォルトではoracle.jbo.domain
パッケージおよびoracle.ord.im
パッケージで最適化した一連の型を使用します。表3-1で示すように、これらの型によって、Oracleデータベースからアクセスしたデータをネイティブな内部形式でデータに保持することができます。ADFビジネス・コンポーネントで提供される最適化されたデータ型を使用し、不要な型変換をなくして処理パフォーマンスを向上させます。文字列データでの作業の場合、ADFビジネス・コンポーネントではデフォルトで通常のjava.lang.String
型を使用します。
表3-1 oracle.jbo.domainパッケージおよびoracle.ord.imパッケージでの基本データ型
データ型 | パッケージ | 説明 |
---|---|---|
|
|
すべての数値データ |
|
|
日付および(オプションの)時間 |
|
|
データベース・トリガーにより割り当てられた、連続した整数 |
|
|
OracleデータベースのROWID |
|
|
タイムスタンプ値 |
|
|
タイムスタンプ値およびタイム・ゾーン情報 |
|
|
JavaVMまたはADF Context(アプリケーションの
このEL式が評価されて現在のユーザーのタイム・ゾーンが決定されるか、この値はJavaVMのタイム・ゾーンにデフォルト設定されます。 |
|
|
バイナリ・ファイル(BFILE)オブジェクト |
|
|
バイナリ・ラージ・オブジェクト(BLOB) |
|
|
キャラクタ・ラージ・オブジェクト(CLOB) |
|
|
Oracle interMediaイメージ(ORDIMAGE) |
|
|
Oracle interMediaオーディオ(ORDAUDIO) |
|
|
Oracle interMediaビデオ(ORDVIDEO) |
|
|
Oracle interMediaドキュメント(ORDDOC) |
|
|
ユーザー定義オブジェクト・タイプ |
|
|
ユーザー定義コレクション・タイプ(例: |
注意:
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メソッド内でカスタム検証ロジックを記述する場合にも役立ちますが、この場合は、ビジネス・コンポーネントでエンティティおよびビュー行実装クラスを生成するかわりに、Groovy式の使用を検討する必要が生じる場合もあります。後続の章では、Javaを使用した実装を選択するビジネス・ロジックのJavaクラスを生成して、強く型付けされた作業スタイルを有効化する方法について説明します。
ビジネス・サービスの次のコンポーネントのみがクライアントに表示されます。
アプリケーション・モジュール: サービス自体を表します。
ビュー・オブジェクト: 問合せコンポーネントを表します。
ビュー行: 指定された問合せコンポーネントの結果の各行を表します。
ビジネス・サービス実装におけるエンティティ・オブジェクトは、クライアントから直接参照されるように設計されていません。かわりに、クライアントは、アプリケーション・モジュールのデータ・モデルの一部として、ビュー・オブジェクトによる問合せデータを処理します。実際には、ビュー・オブジェクトはビジネス・ドメイン・レイヤー内のエンティティ・オブジェクトと自動的に連携し、ユーザーが変更したデータの検証と保存を調整します。この実行時の対話処理の詳細は、6.3.9項「ビュー・オブジェクトとエンティティ・オブジェクトが連携した場合の実行時の処理」を参照してください。
oracle.jbo
パッケージのJavaインタフェースによって、クライアントがアクセス可能なビジネス・サービスに対するAPIが提供されます。このパッケージには、Entity
インタフェース、またはクライアントがエンティティ・オブジェクトを直接操作できるようにするメソッドは含まれていません。かわりに、クライアント・コードが次のようにインタフェースと連携します。
ApplicationModule
: アプリケーション・モジュールを処理します。
ViewObject
: ビュー・オブジェクトを処理します。
Row
: ビュー行を処理します。
クライアントからコール可能にするカスタム・コードをADFビジネス・コンポーネントに追加する場合は、クライアントに表示されるコンポーネントすべてについて、その機能をクライアントに公開できます。JDeveloperでは、クライアント・インタフェース上で1つ以上のカスタム・メソッドをクライアントに公開している各コンポーネントに対して、関連するJavaインタフェース・ファイルが自動的に保持されます。そのため、Fusion Order Demoアプリケーションで使用されるStoreServiceAM
などのアプリケーション・モジュールで作業していると仮定すると、次のようなカスタム・インタフェースを利用できます。
カスタム・アプリケーション・モジュール・インタフェース
StoreServiceAM extends ApplicationModule
カスタム・ビュー・オブジェクト・インタフェース
OrderItemsInfo extends ViewObject
カスタム・ビュー行インタフェース
OrderItemsInfoRowClient extends Row
これにより、クライアント・コードでは、汎用クライアント・インタフェースをより詳細なインタフェースにキャストできます。詳細なインタフェースには、特定のコンポーネントに対して選択した、クライアントからアクセス可能な一連のメソッドが含まれます。
Groovyは、Javaプラットフォーム用のスクリプト言語で、Javaと同様の構文を持ちます。ADFビジネス・コンポーネントのGroovy言語式は、ビジネス・コンポーネントのカスタムJavaクラスで使用するJavaコードとは異なります。Groovyスクリプト言語では、ドット区切り表記法の採用により、コードの作成が簡素化されていますが、コレクション、文字列およびJavaBeansを操作する構文は引き続きサポートされています。Groovy式では型チェックは実行時に行われますが、Javaでは型チェックはコンパイル時に実行されます。また、Groovy式は動的にコンパイルされるため、ビジネス・コンポーネントのXMLファイル定義に保存されたものを使用します。ADFビジネス・コンポーネントは、エンティティ・オブジェクトの属性やビュー・オブジェクトの属性へのアクセスが有用な場所でGroovyスクリプト言語の使用をサポートしており、これには属性バリデータ(エンティティ・オブジェクトの場合)、属性のデフォルト値(エンティティ・オブジェクトまたはビュー・オブジェクトの場合)、一時属性値の計算(エンティティ・オブジェクトまたはビュー・オブジェクトの場合)、バインド変数のデフォルト値(ビュー・オブジェクトの問合せ文およびビュー基準フィルタの場合)、およびエラー・メッセージのプレースホルダ(エンティティ・オブジェクトの検証規則の場合)などが含まれます。さらに、ADFビジネス・コンポーネントには、Groovy式で使用できる組込みキーワードの限定されたセットが用意されています。
特にADFビジネス・コンポーネント・フレームワークでは、次のタスクを実行するための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.14項「エンティティ・オブジェクトへの一時属性および計算属性の追加」および5.14項「ビュー・オブジェクトへの計算属性および一時属性の追加」を参照)
Groovy言語の詳細は、次のWebサイトを参照してください。
フレームワークでGroovyスクリプトを使用できるオブジェクトにアクセス可能な、adf
という名前のトップレベルのオブジェクトが用意されています。アクセス可能な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ビジネス・コンポーネント・ユーザー・セッションへの参照を返します(セッションの一部である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)")