このトピックは、Oracle FormsなどのRapid Application Development(RAD)ツールを使用したクライアント/サーバー・アプリケーションの作成に精通している開発者を対象としています。通常の2層および3層のクライアント/サーバー・アプリケーションでは、開発作業の大部分はクライアント・フォームに集中します。したがって、このトピックではこのタイプのアプリケーションをフォームベースと呼びます。全体を通じて特にOracle Formsを引用しますが、Visual BasicやPowerBuilderなどの他のRADツールに精通しているユーザーにとっても、この情報の多くが役に立ちます。
Oracle ADF Business Componentsについての説明を読む前に、予備知識の有無を確認しておくと有益です。
フォームベース・アプリケーションの開発者は、次の知識があると想定されます。
Oracle ADF Business Componentsを初めて使用する開発者は、次の知識がない場合があります。
知識の多くは簡単に移行でき、その他の知識の習得に必要なのは適切な方向付けのみです。フォームベース・ツールでの開発に関する知識は、Oracle ADF Business Componentsについて理解する際の基盤になります。
FormsとOracle ADF Business Componentsはどちらもアプリケーション・フレームワークです。フレームワークは、データベースとの対話、コミット処理、イベント時の検証の試行など、すべてのアプリケーション処理を行います。フレームワークにより、開発者は、背景の詳細ではなくビジネスに専念できます。
2つのフレームワークの間の主な相違点は、Oracle ADF Business ComponentsではUIをデータ・アクセスから分離することです。後で、この分離によってコンポーネントのアクセスおよび再利用がどのように向上するかを示します。
Formsランタイム・エンジンであるForms Serverは、Forms定義ファイルのデータを実行します。通常、Forms定義は、UIオブジェクト(ウィンドウおよびキャンバス)とデータ・ブロックの両方から構成されます。Forms定義は、メタデータおよび実装コードの2つの部分から構成されます。メタデータは、ブロック、項目、ウィンドウ、キャンバスなどを記述します。ユーザーが作成する実装コードは、トリガーとPL/SQLパッケージ、プロシージャおよびファンクションの組合せです。これらがまとめてFormsの .fmbファイルに格納されます。
上位レベルでは、Oracle ADF Business ComponentsとFormsのアーキテクチャは類似しています。Formsと同様に、メタデータは実装コードとは別に設定されます。ただし、Forms定義ファイルは非常に大きく、多数のデータ・ブロックを含む場合がありますが、Oracle ADF Business Componentsは、各部分をビジネス・コンポーネントと呼ばれる小さなモジュールに分割します。ビジネス・コンポーネントは、JavaクラスとXMLメタデータ・ファイルのペアです。これらの小さなコンポーネントにより、再利用がより適切に行われ、カスタマイズが簡単になります。
アーキテクチャのもう一つの相違点は、コンパイル済Javaコードおよびクライアント(表示)コードの2つに実装コードが分けられることです。
このトピックの後半で両方のフレームワークでのアプリケーション開発について詳細に説明します。この説明によって両者の相違点についての理解が深まります。ただし、その前にビジネス・コンポーネントとは何で、何を行うのかを知っておく必要があります。
ビジネス・コンポーネントを理解するための最も簡単な方法は、すでに理解しているFormsの構成要素と対応付けることです。実際に、ビジネス・コンポーネントのアーキテクチャにFormsのオブジェクトに相当するものが、多くあります。相違点は、ビジネス・コンポーネントがユーザー・インタフェースからデータを分離することから派生しています。次に例を示します。
Formsデータ・ブロックには、2つの主要な機能があります。
データ・ブロックにより、データベース内の行をユーザー・インタフェースから直接操作できます。ユーザーは、データ・ブロックを使用し、その表またはビュー内の行を自動的に問合せ、更新、挿入および削除できます。
Oracle ADF Business Componentsでは、この機能はビュー・オブジェクトおよびエンティティ・オブジェクトという2種類のオブジェクトに分かれています。ビュー・オブジェクトはデータの問合せを行うオブジェクトで、エンティティ・オブジェクトはデータベース内のデータの変更を行うオブジェクトです。機能を2つのオブジェクトに分割することで、同じ検証ロジックおよびデータ操作ロジックを使用し、多くの異なる方法でデータを問い合せることができます。
フォーム内の各データ・ブロックは、使用可能なデータ・ビューを表しています。フォームには、使用可能な値のサブセットが含まれる場合、特定のフィールドが非表示の場合、特定のユーザー・グループにのみ適用される場合などがあります。たとえば、このフォームはEmployeesという名前で、従業員の名前、住所および電話番号のみ表示とします。管理者からアクセスできる同様のフォームには、給与の表示など別のデータ・ビューを表示します。
Oracle ADF Business Componentsは、ビュー・オブジェクトを使用して、この抜粋したデータ・ビューを表します。ビュー・オブジェクトは、SQL問合せを含む再利用可能なコンポーネントです。問合せは、1つまたは多数のデータベース表に基づくことができます。ビジネス・コンポーネント・アプリケーションでは、データの一意のビューは、それぞれ単一のビュー・オブジェクトで表現されます。フォームにデータを表示するために必要な数のビュー・オブジェクトを作成します。
ビュー・オブジェクトとは、データ・ブロックのデータの問合せを行う部分と言えます。
Formsデータ・ブロックと同様に、通常、エンティティ・オブジェクトはデータベース表またはビューに基づいています。エンティティ・オブジェクトは、データベース表を表すクラスと言えます。
フォームベース・アプリケーションでの表の表現は、ビジネス・コンポーネント・アプリケーションのエンティティ・オブジェクトと1対1で対応しています。たとえば、Salesperson、CustomerおよびItemの各表の情報を変更するOrdersフォームの場合、これらの表を表す3つのエンティティ・オブジェクトがあります。
エンティティ・オブジェクトは、データの格納に使用されるだけでなく、データの検証にも使用されます。エンティティ・オブジェクトの検証は、データベース・トリガーの上位レベルで行われ、これが一般に混乱の原因となっています。Oracle ADF Business Componentsでトリガーを使用できますが、エンティティに検証を含める方が、ポストされていないデータに検証を適用できるため有用です。
Formsのリレーションにより実行されるマスター/ディテール機能は、ビュー・リンクにより提供されます。ビュー・リンクは、2つのビュー・オブジェクト間の関係を定義します。ビュー・リンクを定義するには、どのビュー・オブジェクトがマスターであり、どのビュー・オブジェクトがディテールであるか、またそれらをどの列により関連付けるかを指定します。
フォームベース・アプリケーションでは、各フォームは特定のタスク、すなわち単一トランザクション内の作業単位を実行するよう作成されます。たとえば、注文を行うために必要なすべての処理をタスクとするOrderフォームを作成するとします。最初に注文から情報を取得し、次に情報が有効であることを確認し、最後にデータベースに変更をポストします。
Oracle ADF Business Componentsでは、すべてのタスクがアプリケーション・モジュールと1対1で関連付けられます。前述の例では、Orderフォームは単一のアプリケーション・モジュールにより表されます。フォームとは異なり、アプリケーション・モジュールへのユーザー・インタフェース・コンポーネントはありません。アプリケーション・モジュールは、単なるデータおよびその相互関係のモデルです。アプリケーション・モジュールにユーザー・インタフェースのフロント・エンドを組み込むと、フォームと同じ機能になります。
フォームはデータ・ブロックのコンテナで、複数のデータ・ビューからのデータを表示する場合があります。たとえば、Orderフォームに、Customers、ItemsおよびSalespersonの各表に基づくデータ・ブロックを含められます。同様に、タスクが複数のデータ・ビューを使用する必要がある場合は、アプリケーション・モジュールには複数のビュー・オブジェクトが含まれます。アプリケーション・モジュールには、ビュー・オブジェクト間の関係を記述するビュー・リンクも含まれます。
相互に関連付けられているビュー・オブジェクトおよびビュー・リンクは、データ・ブロックおよびリレーションとは異なり、フレームワークによっては調整されません。かわりに、問合せ(ビュー・オブジェクト)およびリレーション(ビュー・リンク)がデータ・モデルにより記述されます。
Oracle Reportsに精通している開発者は、FormsとReportsではデータ・モデルを扱う方法に概念的な違いがあることを理解しています。Formsには、データ・ブロックおよびリレーションにより表される暗黙的なデータ・モデルがあります。Oracle Reportsでは、問合せとリレーションは分離され、データ・モデルを明示的に定義できます。問合せからデータ・モデルを構築し、問合せ間にリンクを設定できます。
Reportsと同様に、Oracle ADF Business Componentsのデータ・モデルも明示的ですが、これはビュー・オブジェクトおよびビュー・リンクによりアプリケーション・モジュールに記述されます。これらの類似点に基づくと、Oracle ADF Business Componentsは、Reportsにより提供されるデータの分離とFormsにより提供されるデータ操作を可能にしていると言えます。
2つのデータベース表がキーによりリンクされている場合、これは、ビジネス・コンポーネントではアソシエーション・オブジェクトにより表されます。アソシエーションにより、関連する表からデータを取得できます。
アソシエーションは、データベース外部キー制約がデータベースで検出されると、ビジネス・コンポーネント・フレームワークにより自動的に作成されます。ビジネス・コンポーネントのウィザードを使用してアソシエーションを直接作成することもできます。ビュー・リンクは、基礎となるアソシエーションを使用して簡単に作成できます。これにより、関連する情報の取得およびその情報のUIへの表示が非常に簡単になります。
先に進む前に、ビジネス・コンポーネントの役割およびビジネス・コンポーネントとForms構成要素との関連を再確認することにより、これまでの説明を要約します。
FormsおよびOracle ADF Business Componentsでは、どちらもフレームワーク・レベルのコンテナの作成から開始します。Formsではこれをフォーム・モジュールと呼びますが、Oracle ADF Business Componentsではこれをプロジェクトと呼びます。次に、データベースと通信するオブジェクトが作成されます。Formsではこれをデータ・ブロックと呼び、Oracle ADF Business Componentsではこれらをビジネス・コンポーネントと呼びます。ここまでは、アプリケーション開発はかなり類似しています。
最初の相違点は、Oracle ADF Business Componentsでは、Formsとは異なり、データ要素がUIに関連付けられないことです。Oracle ADF Business Componentsでは、UIコンポーネントは任意の数の基礎となるデータベース表から情報を取得できます。Formsでは、UI要素を直接レイアウトすることから開始できますが、Oracle ADF Business ComponentsではUIを別途作成します。
もう一つの相違点は、UIからのビジネス・ロジックの分離に関連するもので、ビジネス・ルールを実行する方法です。
従業員がデータを表示および変更できるアプリケーションを作成するとします。実装する必要のあるビジネス・ルールには、次のものがあります。
フォームベース・アプリケーションでは、クライアント・フォームはリストやオプション・ボタンなどのUIコントロールを介してビジネス・ルールを実行します。検証は、テキスト・フィールドがフォーカスを失うなどのUIイベント、または新規行の挿入などのデータベース・イベントを介して実行されます。
検証する必要のある3つの条件は、次の方法で行うことができます。
同じ3つのビジネス・ルールをOracle ADF Business Componentsで実行するには、クライアントまたはデータベースには検証をコーディングしません。かわりに、ビジネス・ロジック層に検証コードを作成します。
別の類似フォームを作成する必要があるとします。このフォームは、管理者からアクセスでき、給与情報を追加で表示します。典型的なRAD環境では、これは各種フィールドなどに検証コードを結び付ける新規UIの作成を意味します。
Oracle ADF Business Componentsでは、すべての検証を再コーディングせずに再利用できます。すべての検証はエンティティ・オブジェクトに含まれているため、エンティティを使用することにより検証を行えます。これにより、再利用性が大幅に向上します。また、ビジネス・ルールが変更された場合、たとえばパスワードに8文字が必要になった場合は、エンティティ・オブジェクトを編集してその変更を反映することで、データのすべてのビューを同時に更新できます。ビジネス・ルールの再利用は、Oracle ADF Business Componentsの1つの重要な利点です。もう一つの利点は、フレームワークの柔軟性です。
Forms開発者にとって、Formsフレームワークの動作の変更が非常に難しいことは、デメリットの1つです。特定の方法で動作するナビゲーションまたは検証が必要な場合は、トリガーを作成することにより、フレームワークを回避する必要があります。実際に開発者は、アプリケーションの動作をカスタマイズするために、フレームワークのデフォルトの動作を回避するトリガーの作成に長時間を費やすことがあります。
Oracle ADF Business Componentsでは、ベース・ビジネス・コンポーネント・クラスから新規ビジネス・コンポーネントを拡張したり、既存のビジネス・コンポーネントのかわりに新規ビジネス・コンポーネントを使用できます。これは、エンタープライズ・アプリケーションがデプロイされた後、元のソース・コードを変更せずにエンタープライズ・アプリケーションを変更できることを意味します。
Formsでは、マスター/ディテール・フォームの操作中に別のフォームに変更を加える際に、操作しているフォームへの変更をまずコミットする必要があります。フォームの操作の終了前に変更のコミットが強制されることがあるため、これはユーザーにとってデメリットになります。フォームは独立しているように見えるため、このようなユーザー・インタフェースでは誤解を招く場合があります。相互に依存しているフォームを使用する場合、このモデルでは操作が非常に難しくなります。
また、ユーザーが操作しているフォームでタスクを完了するために別のフォーム内の情報が必要な場合、ユーザーは他のフォームに対して問合せを実行し、その情報を検索する必要があります。検索で得られた複数の問合せ結果を参照した後、詳細情報を表示する詳細画面を参照し、そこで情報を収集します。
Oracle ADF Business Componentsでは、ユーザーは複数のフォームを同時に処理できます。1つのレコードで行われた変更は、複数のフォームに反映されます。ユーザーは、オブジェクトとの間で問合せを行い、必要な変更を行うことができます。あるフォーム上のタスクが他のフォームに関連している場合、フォーム間の相互作用はシームレスです。最後に、ユーザーは、フレームワークで必要なときではなく、作業の完了時に変更をコミットできます。
Oracle ADF Business Componentsでは、ユーザーが複数のフォームを同時に処理できますが、この機能には制限があり、フレームワークはフォーム・レベルでブロック(またはレコード)の内容を消去できません。
Formsでは、CLEAR_BLOCK(またはCLEAR_RECORD)により、単一のブロックで行われたすべての変更を消去し、最初からやりなおすことができます。消去対象のビュー・オブジェクトは、他のビュー・オブジェクトを変更している可能性があり、これらの変更は個々のビュー・オブジェクトでは管理されないため、これをOracle ADF Business Componentsで行うことはできません。このデータ管理がアプリケーション・モジュール・レベルで行われるため、複数のフォームを同時に処理できます。フォーム・レベルでデータを消去する機能が必要な場合は、フレームワークではなくUIで管理する必要があります。
FormsおよびOracle ADF Business Componentsはどちらもアプリケーション・フレームワークであり、上位レベルでは同様のアーキテクチャおよび概念を共有します。ただし、Oracle ADF Business Componentsの方が、メタデータをUIから分離する、きめ細かいソリューションです。これには、ビジネス・ロジックを簡単に再利用できる、フレームワークをカスタマイズできる、クライアントに依存しないビジネス・ロジック層、アプリケーション・レベルでのデータのキャッシュなど、多くの利点があります。
Oracle ADF Business Componentsの概要
Copyright © 1997, 2007, Oracle. All rights reserved.