E ADF Business Components Java EEデザイン・パターン・カタログ

この付録では、ADF Business Components層によって自動的に実装されるJavaプラットフォームEnterprise Edition(Java EE)デザイン・パターンの概要を示します。

Oracle Application Development Frameworkのビジネス・コンポーネント部品とJDeveloper用の関連する設計時拡張機能を使用すると、高性能かつ機能豊富で正確な階層構造を持つJava EEビジネス・サービスを構築するための規範的なアーキテクチャが得られます。

ADF Business Components層によって自動的に実装される多数の設計パターンの概要を、表E-1に示します。おなじみのSunのJava EE Blueprintsのパターンもあれば、ADF Business Componentsによって追加されたデザイン・パターンもあります。Java EE BluePrintsの詳細は、Oracle Technology Network WebサイトのBluePrintsのページ(http://www.oracle.com/technetwork/java/index-jsp-136701.html)を参照してください。

表E-1 ADF Business Componentsによって実装されるJava EEデザイン・パターン

パターンの名前と説明	ADF Business Componentsによる実装方法
モデル/ビュー/コントローラ データおよびプレゼンテーションの役割が正しく分割され、複数のタイプのクライアント・ディスプレイで同じビジネス情報を使用できます。	ADFアプリケーション・モジュールが提供するモデル/ビュー/コントローラというアプリケーション・オブジェクトの汎用的な実装により、あらゆるアプリケーションまたはサービスに対するアプリケーション・データ・モデルの公開が簡単になり、論理的な作業ユニットの境界を宣言的に指定することが容易になります。JDeveloperではUI中心のフレームワークおよびタグ・ライブラリも提供され、これによりビュー・レイヤーおよびコントローラ・レイヤーを簡単に実装できます。
インタフェース/実装の分離 コンポーネントのAPIまたはインタフェースが、その実装クラスから正確に分離されます。	ADF Business Componentsにより、クライアント層から(インタフェースを介して)アクセス可能な機能とそのビジネス層の実装の論理的な分離が強制されます。カスタム・インタフェースおよびクライアント・プロキシ・クラスの作成は、JDeveloperにより自動的に処理されます。
サービス・ロケータ クライアントからより簡単に使用できるように、サービスの検索に関する技術的な詳細情報が抽象化されます。	ADFアプリケーション・モジュールの検索に使用されるシンプルな構成オブジェクトにより、背後にあるサービス・インスタンスを検索するための低レベルの詳細情報が隠蔽されます。Fusion Webアプリケーションの場合は、アプリケーション・モジュール・プール(一連のサービス・コンポーネントから構成される軽量プールであり、アプリケーションの拡張性を改善する)の実装も隠蔽されます。
制御の逆転 格納側コンポーネントは、ユーザーがコードの実行時期よりも実行内容を重視できるように、適切な時期にオーバーライド可能な特定のメソッドを起動することで、格納しているコンポーネントのライフサイクルを調整します。	ADFコンポーネントには、アプリケーションの処理過程で必要に応じてフレームワークによって起動される、オーバーライドが容易な一連のメソッドが含まれています。
依存性注入 コンポーネントの構成とコンテナへのアセンブリを保留することにより、アプリケーション・コードが簡単になり、構成の柔軟性が高くなります。	ADFビジネス・コンポーネントは、外部のXMLメタデータ定義ファイルからそのすべてのコンポーネントを構成します。実行時に、そのフレームワークにより、ビュー・オブジェクト・インスタンスのような依存オブジェクトはアプリケーション・モジュール・サービス・コンポーネントに、エンティティ・オブジェクトはビュー行に自動的に注入されるので、遅延ロードが実装されます。コンポーネントのカスタマイズされた任意のサブクラスによる該当コンポーネントの実行時ファクトリ置換がサポートされるので、オンサイトでのアプリケーションのカスタマイズが容易になります。ADFビジネス・コンポーネント機能の大半はバリデータ・サブスクリプションおよびリスナー・サブスクリプションの動的注入によって実装されますが、それにより、XMLメタデータ内の各コンポーネントで構成されている宣言的な機能に基づいて、フレームワークのやり取りが調整されます。
アクティブ・レコード データベース表またはデータベース・ビュー内の1行をラップしてデータベース・アクセスをカプセル化し、該当するデータ上でドメイン・ロジックを追加するようなオブジェクトを提供することにより、「すべてのものからすべてのものへ」というオブジェクト・リレーショナル・マッピングの複雑性が回避されます。	継承、関連付け、コンポジットのサポートなど、最も頻繁に使用されるデータベース・マッピング機能はADFエンティティ・オブジェクトにより処理されますので、ユーザーはオブジェクト・リレーショナル・マッピングに重点を置く必要はありません。また、これらのオブジェクトは、宣言的なビジネス・ルールと1回限りのプログラム的なビジネス・ドメインの両方をカプセル化する場所も提供します。
データ・アクセス・オブジェクト 依存オブジェクトをそれぞれ個別にエンタープライズBeanとして実装するのではなく、一連の軽量の永続クラスとして実装することにより、不要なマーシャリングのオーバーヘッドを防ぎます。永続性に関する詳細が、メンテナンスが簡単な単一のクラスに分離されます。	ADFビュー・オブジェクトは、SQL文を使用してデータを読み取るためのデータ・アクセスの実装を自動化します。ADFエンティティ・オブジェクトは、軽量ビジネス・エンティティの永続的な保存を自動化します。ADFのビュー・オブジェクトとエンティティ・オブジェクトが協力して提供する高度で高性能なデータ・アクセス・オブジェクト層では、ビュー・オブジェクトを介して問合せが行われるデータを任意で完全に更新可能にすることもできます。アプリケーションを処理するコードを記述する必要はありません。
セッション・ファサード セッションBeanを使用してエンティティBeanをラップすることにより、エンティティBeanの非効率的なクライアント・アクセスと機密性の高いビジネス情報の不注意な露見を防ぎます。	ADFアプリケーション・モジュールは、サポートされているどのデプロイ・モードでも粒度の粗いサービス・ファサード・アーキテクチャを実装するように設計されています。EJBセッションBeanまたはサービス・インタフェースとしてデプロイされると、セッション・ファサード・パターンが自動的に実装されます。
値オブジェクト 1回かぎりのトランスポート・オブジェクトを作成し、クライアント・プログラムに必要な、関連する一連の属性をグループ化することにより、ネットワークの不必要なラウンドトリップを防ぎます。	ADFビジネス・コンポーネントによって実装される汎用的なRowオブジェクトは、クライアントからアクセスする必要がある任意の数および種類の属性から構成されるメタデータ・ドリブンのコンテナです。開発者は、汎用的なRowインタフェースを使用して遅延バインドのgetAttribute("Price")コールおよびsetAttribute("Quantity")コールを実行するか、OverdueOrdersRowのような早期バインドのRowインタフェースを生成して、getPrice()やsetQuantity()のような型保証メソッド・コールを有効にすることができます。ADF Rowオブジェクトは、単純な属性の集合よりも洗練されており、実行時に見直して行内の属性の数、名前およびタイプを規定することが可能なため、高度で汎用的なソリューションを実装することができます。
ページごとのイテレータ 1つの大きな塊をページサイズの一連のチャンクに分割して表示することにより、不必要なデータの送信を防ぎます。	ADFビジネス・コンポーネントによって実装される汎用的なRowSetインタフェースは、ビュー・オブジェクトSQL問合せの実行によって生成された結果セットを管理します。このRowSetを使用して望ましいページサイズ(たとえば10行)を設定し、そのページサイズのチャンク単位で問合せ結果のページを上下に移動できます。データは遅延して取得されるため、ユーザーが実際にアクセスしたデータのみがバックエンドでデータベースから取得され、クライアント層ではページ内の一連の行がネットワークを介して1回のラウンドトリップで返されます。
優先リーダー JDBC APIに直接アクセスすることにより、読取り専用データに対する不必要なオーバーヘッドを防ぎます。これにより、アプリケーションはクライアントの要求がほんのわずかであるときに、主キーを基準にすべての属性を検索するのではなく、表示する必要のある属性のみを取得できるようになります。一般に、RAW JDBCレベルで実行される問合せは、エンタープライズBeanで表されるビジネス情報に対して行われたが、保留になっている変更を「見ない」ため、このパターンを実装すると、パフォーマンスでのデータの一貫性が犠牲になります。	ADFビュー・オブジェクトは最適なパフォーマンスのためにデータベースから直接データを読み込みますが、データの一貫性に関する選択肢も用意されています。保留中の変更についての更新の可能性や一貫性が重要である場合は、ビュー・オブジェクトと、ビジネス・データが提示されているエンティティ・オブジェクトとの関連付けのみが必要です。一貫性は問題ではない場合、ビュー・オブジェクトは単純に問合せを実行できます。オーバーヘッドは発生しません。どちらの場合も、JDBCデータ・アクセス・コードを記述する必要はありません。XMLディスクリプタへの適切なSQL文の提供のみが必要です。
(Bean)ファクトリ 外部構成が可能な情報に基づいて、指定のインタフェースまたはスーパークラスの適切なサブクラスのインスタンス化および構成を実行時に実行できます。	すべてのADFのコンポーネントのインスタンス化は、ファクトリ・クラスを使用し、XML構成メタデータに基づいて実行されます。そのため、特殊なコンポーネントの実行時置換が可能になり、アプリケーションのカスタム化が促進されます。
エンティティ・ファサード 1つ以上のビジネス・エンティティのデータおよび動作の制限的ビューを提供します。	ADFのビュー・オブジェクトは、基礎となる1つ以上のエンティティ・オブジェクトの組合せから属性およびメソッドの任意のセットを公開し、操作対象となる単一の論理値オブジェクトをクライアントに提供できます。
Value Messenger クライアントの値オブジェクトの属性と、双方向に表示される中間層のビジネス・エンティティ情報の同期が維持されます。	ADFビジネス・コンポーネントの値オブジェクトの実装により、クライアント側値オブジェクトとの調整が実行され、EJB層に対するバッチ属性変更のキャッシング、および中間層ビジネス・ロジックの結果として発生するバッチ属性更新の受信が実行されます。ADF Value Messengerの実装は、これを実現するためのどのような種類の非同期メッセージングも必要としないように設計されています。
続行 ステートレスなWebソリューションの拡張性を備えたステートフルなプログラミング・モデルの容易さおよび生産性を提供します。	この付加価値は、ADFビジネス・コンポーネントのアプリケーション・モジュール・プーリングと状態管理機能を組み合せたものです。アプリケーション・モジュール・プーリングにより、個々のユーザーにアプリケーション・サーバー層リソースを割り当てる必要がなくなり、ユーザーによる調整が可能で、ユーザー・アフィニティについてステートレスな最適化がサポートされます。