| Oracle® Fusion Middleware Oracle TopLinkの理解 12c (12.1.2) E48006-01 |
|
 前 |
 次 |
アプリケーションの設計を最適化するために、反復型の段階的な開発プロセスに従うことをお薦めします。TopLinkの柔軟性によって、任意の開発ツールを使用できます。
次の項では、推奨される開発プロセスについて説明します。
この項では、EclipseLinkアプリケーションの一般的な開発段階について説明します。図3-1に、開発プロセスを示します。
アプリケーションの設計(1)
アプリケーション要件を定義し、アーキテクチャを選択し、ターゲット・プラットフォームを決定します。EclipseLinkは、任意のアーキテクチャと任意のプラットフォームで使用できます。
アプリケーションを設計する際、そのアプリケーションに対するオブジェクト・モデルも作成する必要があります。不適切なモデルまたは急速に変化するモデルに対して永続的なマッピングを定義することは非常に難しいため、オブジェクトをマップする前にオブジェクト・モデルを作成することが重要です。詳細は、3.5項「オブジェクトの永続化について」を参照してください。
アプリケーションの開発(2、3、4)
Javaクラスを作成し、そのクラスがデータ・ソースによってどのように実装される必要があるかを決定します。レガシー・システムを使用する場合、クラスが既存データにどのように関連するかを決定します。統合するレガシー・データ・ソースがない場合は、データ・ソースに各クラスを格納する方法を決定し、必要なスキーマを作成します。または、EclipseLinkを使用して初期の表を作成することもできます。
JDeveloperなどの開発ツールを使用して、永続クラスに対するディスクリプタとマッピングを作成します。セッションを使用して、永続クラスの操作(データの問合せおよび変更など)を行います。詳細は、1.6項「主要ツール」を参照してください。
1回の開発サイクルで、モデルのディスクリプタをすべて作成することは避けます。クラスの小さなサブセットから開始してください。それらのディスクリプタを作成およびテストしてから、段階的に新規のディスクリプタとリレーションシップを追加します。これにより、一般的な問題が設計全体にわたって拡散する前にこのような問題を捕捉できます。
データベース・セッションを使用するJavaコードを記述します。セッションは、データベース・オブジェクトの問合せおよびデータベースへのオブジェクトの書込みに使用します。
アプリケーションのデプロイ(5)
必要なファイルを生成し、パッケージ化して、アプリケーション・サーバーにデプロイします。必要な情報は、環境およびアーキテクチャによって異なります。
アプリケーションのメンテナンス(6)
EclipseLinkには、アプリケーションのパフォーマンスを向上させるための数多くのオプションが含まれています。EclipseLinkの大部分の機能は、要件に合うようにカスタマイズできます。高度なEclipseLinkの機能を使用したりカスタム問合せルーチンを記述して、特定の方法でデータベースにアクセスし、パフォーマンスを最適化します。
アプリケーションを設計する際、どこでどのようにEclipseLinkを使用するかを選択する必要があります。Java対応の各種プラットフォーム上で、様々な永続性およびデータ変換機能を実行できます。アプリケーション・アーキテクチャを設計する場合、これらの機能に留意してください。
EclipseLinkでは、次のようなJavaを使用するすべてのエンタープライズ・アーキテクチャをサポートします。
Java EE
Spring
Java Webサーバー(Tomcatなど)
Javaクライアント(Java SE、Webブラウザなど)
サーバーのJavaプラットフォーム
開発者によるEclipseLinkの使用方法および構成方法は、ホストのJavaまたはJava EE環境にデプロイするための、特定のターゲット・プラットフォームでのアプリケーションのパッケージ化要件の影響を受けます。たとえば、Java EEアプリケーションをエンタープライズ・アーカイブ(EAR)ファイルにパッケージします。EARファイル内では、永続エンティティをWeb Archive (WAR)およびJava Archive (JAR)ファイル内にパッケージするための方法がいくつかあります。開発者によるEclipseLinkの構成方法は、部分的に、アプリケーションのパッケージ方法およびホスト・アプリケーション・サーバーのクラス・ローダーの使用方法に依存します。
サポートされるアプリケーション・サーバーのバージョン、カスタム統合、構成要件の詳細は、5.1項「アプリケーション・サーバーとの統合」を参照してください。
EclipseLinkでは、クラスが永続クラスになるには特定の最低要件を満たしている必要があります。EclipseLinkでは、大部分の要件を満たすための代替方法も用意しています。EclipseLinkは、オブジェクト・モデルへの介入を最小限にできるメタデータ・アーキテクチャを使用した、非介入型アプローチを使用します。
この項では、次の内容について説明します。
EclipseLinkを使用して永続層を実装する際は、次のオプションを検討してください。
JPAを使用している場合は、標準のJPAの注釈およびpersistence.xml、EclipseLink JPAの注釈の拡張機能およびEclipseLink JPAのpersistence.xmlの拡張機能を任意に組み合せて永続層コンポーネントを指定できます。
詳細は、2.1.3項「構成の基本について」を参照してください。
永続層コンポーネントは、Javaでコーディングまたは生成できます。Javaコードを使用するには、project、login、platform、descriptorsおよびmappingsなど、プロジェクトの各要素に関して、コードを手動で記述する必要があります。アプリケーションがモデルベースであり、コード生成に強く依存する場合は、TopLink Workbenchを使用した方が効率的です。
クラスのフィールド(データ・メンバー)にアクセスする際は、getter/setterメソッドを使用してアクセスするか(プロパティ・アクセスとも呼ばれる)、フィールド自体に直接アクセスできます。
メソッド・アクセスと直接フィールド・アクセスのどちらを使用するかは、アプリケーション設計によって決まります。次のガイドラインを考慮してください。
クラス外ではメソッド・アクセスを使用します。
これは、クラスの本来のパブリックAPIです。getter/setterメソッドは、必要なすべての副次的な処理を行うため、クライアントはその詳細を認識する必要がありません。
クラス内では、パフォーマンス向上のため直接フィールド・アクセスを使用します。
この場合は、getter/setterメソッドを使用しないために起動されない副次的な処理を考慮に入れる必要があります。
メソッド・アクセスと直接フィールド・アクセスのどちらを使用するかを検討する際は、次の制限を考慮してください。
getter/setterメソッドで変更追跡を有効にした場合(たとえば、メソッドsetPhoneを@ChangeTrackingで修飾した場合)は、クライアントでgetter/setterメソッドを使用してフィールド(phone)を変更すると、EclipseLinkではその変更を追跡します。
同様に、フィールドで変更追跡を有効にした場合(たとえば、フィールドphoneを@ChangeTrackingで修飾した場合)は、クライアントでフィールド(phone)を直接変更すると、EclipseLinkではその変更を追跡します。
ただし、getter/setterメソッドで変更追跡を有効にした場合(たとえば、メソッドsetPhoneを@ChangeTrackingで修飾した場合)でも、クライアントがフィールド(phone)に直接アクセスする場合は、EclipseLinkでは変更を検出しません。クラス内ではパフォーマンス向上のためフィールド・アクセスを、クラス外ではメソッド・アクセスを使用する形式でのコーディングを選択する場合は、この制限に注意してください。
詳細は、『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@ChangeTracking注釈の説明を参照してください。
ウィービングは、コンパイル済のJavaクラスのバイトコードを操作する方法です。
JPAエンティティとPlain Old Java Object (POJO)クラスの両方のパフォーマンスを向上するために、遅延ロード、変更追跡、フェッチ・グループ、内部最適化などの操作にウィービングを使用します。
詳細は、3.7項「ウィービングについて」を参照してください。
永続Javaオブジェクトを作成する場合、privateまたはprotected属性で直接アクセスを使用します。
ウィービングを使用している場合、ValueHolderInterfaceは必要ありません。詳細は、3.7項「ウィービングについて」を参照してください。インダイレクションおよび透過インダイレクションの詳細は、7.2.1項「インダイレクション(遅延ロード)」を参照してください。
アプリケーションの永続層の目的は、実行時にセッションを使用してマッピング・メタデータとデータ・ソースを関連付け(第8章「データ・アクセスの理解」を参照)、EclipseLinkのキャッシュ、問合せと式、およびトランザクションを使用して永続オブジェクトの作成、読取り、更新および削除を行うことです。
通常、EclipseLink永続層には次のコンポーネントが含まれます。
EclipseLinkアプリケーションのメタデータ・モデルは、プロジェクトに基づいています。プロジェクトは、ディスクリプタ、マッピングおよびランタイム機能をカスタマイズする各種ポリシーで構成されています。セッションからプロジェクトを参照することにより、このマッピングと構成情報を特定のデータ・ソースとアプリケーションに関連付けます。
詳細は、次を参照してください。
デフォルトでは、EclipseLinkセッションはオブジェクト・アイデンティティを保証するオブジェクトレベルのキャッシュを提供し、アプリケーションがデータ・ソースにアクセスする回数を減らしてパフォーマンスを向上します。EclipseLinkは、ロック、リフレッシュ、無効化、分離およびコーディネーションなどの、様々なキャッシュ・オプションを提供します。キャッシュ・コーディネーションを使用して、デプロイされたアプリケーションの他のインスタンスと変更を同期化するようにEclipseLinkを構成できます。永続性ユニットまたはエンティティ・レベルでほとんどのキャッシュ・オプションを構成できます。また、問合せ単位またはディスクリプタでキャッシュ・オプションを構成して、参照クラスのすべての問合せに適用されるようにできます。
詳細は、第9章「キャッシュの理解」を参照してください。
オブジェクト・リレーショナル・アーキテクチャでは、EclipseLinkによって、複数のオブジェクトおよびデータ問合せタイプが提供され、次のように問合せ選択基準の柔軟なオプションを使用できます。
EclipseLink式
JPQL (Java Persistence Query Language)
SQL
ストアド・プロシージャ
例による問合せ
これらのオプションを使用して、あらゆるタイプの問合せを作成できます。名前付き問合せを使用してアプリケーション問合せを定義することをお薦めします。名前付き問合せは、プロジェクトのメタデータ内に保持され、名前で参照されます。これにより、アプリケーション開発は簡単になり、問合せはカプセル化されてメンテナンス・コストが軽減します。
オブジェクト・リレーショナル・アーキテクチャでは、永続エンティティ・タイプとは無関係に任意の問合せオプションを自由に使用できます。また、EclipseLink APIを使用してコードで問合せを作成することもできます。
|
注意: これらの問合せ方法は、Object-XML (OXM、JAXB)マッピングでは使用できません。ただし、レガシーEIS XMLプロジェクトを使用する場合は、問合せを実行できます。 |
詳細は、第10章「問合せの理解」および第11章「EclipseLinkの式の理解」を参照してください。
アプリケーションのパッケージ化(JavaまたはJava EEのホスト環境にデプロイするため)は、EclipseLinkの使用方法および構成方法に影響します。たとえば、開発者はJava EEアプリケーションをEARファイルにパッケージします。EARファイル内では、永続エンティティをWARおよびJARファイル内にパッケージするための方法がいくつかあります。開発者によるEclipseLinkの構成方法は、部分的に、アプリケーションのパッケージ方法およびホスト・アプリケーション・サーバーのクラス・ローダーの使用方法に依存します。
EclipseLinkのデプロイ方法では、アプリケーション・ファイルをJARファイルやEARファイルなどの1つのファイルにパッケージ化します。この方法に従うと、ファイル管理をそれほど必要としない、クリーンな自己完結型のデプロイ・ファイルを作成できます。これらのファイルを作成した後、プロジェクトをデプロイします。
詳細は、第5章「アプリケーション・デプロイメントの理解」を参照してください。
この項では、リレーショナル・マッピングについて簡単に説明し、オブジェクト・モデリングとリレーショナル・モデリングへの手引きとなる情報および制限が提供されます。この情報は、アプリケーションを作成するときに役立ちます。
この項では、次の内容について説明します。
オブジェクト・モデリングとは、アプリケーション・オブジェクトを表現するJavaクラスを設計することです。自分で選んだ統合開発環境(IDE)またはUnified Modeling Language (UML)モデリング・ツールを使用して、アプリケーション・オブジェクト・モデルを定義および作成できます。
EclipseLinkデータベース・セッションにディスクリプタを登録するクラスは、すべて永続クラスと呼ばれます。EclipseLinkでは、永続クラスは、データベースに格納されるあらゆるprivateまたはprotected属性に対してpublicアクセッサ・メソッドを提供する必要はありません。詳細は、3.3.2項「永続クラス要件」を参照してください。
データ・ストレージ・スキーマとは、アプリケーションの永続データを編成するために実装する設計のことです。このスキーマは、永続データ自体を参照するのであって、実際のデータ・ソースを参照するのではありません(例、リレーショナル・データベースや非リレーショナル・レガシー・システム)。
アプリケーション開発プロセスの設計フェーズで、データ・ソースのクラスの実装方法を決定する必要があります。既存のデータ・ソース情報を統合する場合、クラスと既存データの関係を確認する必要があります。統合するレガシー情報がない場合は、各クラスを格納する方法を決定してから必要なスキーマを作成します。詳細は、3.1項「一般的な開発段階」を参照してください。
オブジェクトを永続化する場合、各オブジェクトには、格納および取得時にそれを一意に識別するためのアイデンティティが必要です。オブジェクト・アイデンティティは、一般に一意の主キーを使用して実装されます。このキーは、各オブジェクトを識別し、参照を作成および管理するために、EclipseLinkによって内部的に使用されます。オブジェクト・アイデンティティが損われると、オブジェクト・モデルが破損することがあります。
Javaアプリケーションでは、メモリー内の各オブジェクトが1つのみのオブジェクト・インスタンスによって表される場合にオブジェクト・アイデンティティが維持されます。同じオブジェクトの複数取得は、同一オブジェクトの複数コピーを返すのではなく、同一オブジェクト・インスタンスへの参照を返します。
EclipseLinkは、複数アイデンティティ・マップをサポートして、オブジェクト・アイデンティティを保持します(コンポジット主キーを含む)。詳細は、9.2項「キャッシュのタイプとサイズについて」を参照してください。
EclipseLinkでは、メタデータを使用して、オブジェクトおよびBeanのデータ・ソースへのマップ方法を記述します。このアプローチによって、永続性情報とオブジェクト・モデルが分離されるため、開発者は自由に理想的なオブジェクト・モデルを設計し、DBAは自由に理想的なスキーマを設計できます。詳細は、3.6項「メタデータについて」を参照してください。
実行時に、EclipseLinkはメタデータを使用して、アプリケーションが必要とするたびにシームレスおよび動的にデータ・ソースと対話します。
EclipseLinkは、オブジェクト・モデルに含まれる可能性のある様々なデータ・タイプと参照をサポートする、広範なマッピング階層を提供します。詳細は、第7章「マッピングの理解」を参照してください。
外部キーは、別の表の一意キー(通常は主キー)を参照する1つ以上の列です。主キーと同様、外部キーは任意の数のフィールドで、これらすべてが1つの単位として扱われます。外部キーと参照先の親である主キーは、フィールドの数およびタイプが同じである必要があります。
外部キーは、1つの表の1つ以上の列から別の表の1つ以上の列へのリレーションシップを表します。たとえば、すべてのEmployeeに属性addressがあり、この属性にAddress(独自のディスクリプタおよび表を所有)のインスタンスが含まれている場合、address属性に対する1対1マッピングにより、特定のEmployeeの住所を見つけるための外部キー情報が指定されます。
オブジェクト指向システムでは、クラスを、他のクラスに基づいて定義できます。たとえば、オートバイ、セダンおよびバンは、すべて乗り物の種類です。それぞれの乗り物タイプは、Vehicleクラスのサブクラスです。同様に、Vehicleクラスは、特定の各乗り物タイプのスーパークラスです。各サブクラスはそのスーパークラスから属性およびメソッドを継承します(これらにそのクラス独自の属性とメソッドを追加します)。
継承により、次のようなアプリケーションの利点が提供されます。
サブクラスを使用することにより、スーパークラスから提供された共通の要素をベースとして特殊化した動作を提供できます。継承を使用することで、スーパークラスのコードが何度も再利用できます。
一般的な動作を定義する抽象スーパークラスを実装できます。この抽象スーパークラスは、動作を定義し一部実装できます。詳細については、特殊化したサブクラスを使用して完成します。
同時クライアントを同時にログインさせるには、サーバーが各クライアント用に実行の専用スレッドを生成する必要があります。これは、Java EEアプリケーション・サーバーによって自動的に行われます。専用スレッドにより、各クライアントは他のクライアントの完了を待たずに作業できるようになります。EclipseLinkは、これらのスレッドがアイデンティティ・マップを変更するときやデータベース・トランザクションを実行する際、互いに干渉しないように保証します。クライアントは、独立したスレッド・セーフな方法でトランザクションを変更できます。EclipseLinkは、変更するオブジェクトのクローンを管理することで、各クライアントの作業を他の同時クライアントおよびスレッドから分離します。これは、本質的に、データベース・トランザクションとしてACID (Atomicity、Consistency、Isolation、Durability)トランザクション方針のすべてを維持する、オブジェクトレベルのトランザクション・メカニズムです。
EclipseLinkでは、オプティミスティックおよびペシミスティック・ロック方法が構成できるようにサポートされていて、EclipseLink並行性マネージャが使用するロックのタイプをカスタマイズできます。詳細は、6.2.4項「ディスクリプタとロック」を参照してください。
EclipseLinkキャッシュは、データベースからオブジェクトとして返されたデータを将来の使用のために自動的に保存しておくことにより、アプリケーションのパフォーマンスを向上させます。このキャッシュにはいくつかの利点があります。
データベースから以前に読み取られたJavaオブジェクトを再利用することで、データベース・アクセスが最小限に抑えられます。
オブジェクトがキャッシュにすでに存在している場合、データベースへのSQLコールが最小限に抑えられます。
データベースへのネットワーク・アクセスが最小限に抑えられます。
キャッシュ・ポリシーはクラス単位またはBean単位に設定できます。
キャッシュのオプションおよび動作のベースを、Javaガベージ・コレクションにすることができます。
EclipseLinkには、複数のキャッシュ・ポリシーがサポートされているという高い柔軟性があります。開発者は、個々のアプリケーション・パフォーマンスに基づいて、パフォーマンスを最大限にするためにキャッシュを微調整できます。詳細は、第9章「キャッシュの理解」を参照してください。
EclipseLinkの非介入型のアプローチでは、メタデータ・アーキテクチャを通じて永続性を実現するため、オブジェクト・モデルへの介入がほとんどありません。
Javaオブジェクトを永続化する際、EclipseLinkでは次のいずれも不要です。
永続スーパークラスまたは永続インタフェースの実装
オブジェクト・モデルにおける必要なメソッドの保存、削除またはロード
特別な永続メソッド
オブジェクト・モデルへのソース・コードの生成またはラップ
この非介入型アプローチの詳細は、3.3項「永続層の構築および使用」を参照してください。3.6項「メタデータについて」も参照してください。
インダイレクション・オブジェクトは、アプリケーション・オブジェクトのかわりとなるため、アプリケーション・オブジェクトは必要とされるまでデータベースから読み取られません。インダイレクション(JPAでの遅延ロード)を使用すると、EclipseLinkで関連オブジェクトのスタンドインを作成できます。これにより、特にアプリケーションが取得したオブジェクトのみのコンテンツを必要とし、そのオブジェクトに関連するすべてのオブジェクトのコンテンツは必要としない場合に、パフォーマンスの大幅な向上が見られます。
インダイレクションがない場合、アプリケーションが永続オブジェクトを取得するたびに、そのオブジェクトで参照されるオブジェクトもすべて取得されます。これは、アプリケーションによってはパフォーマンスの低下につながります。
|
注意: 常にインダイレクションを使用することをお薦めします。 |
EclipseLinkは、プロキシ・インダイレクション、透過インダイレクションおよびValueHolderインダイレクションなど、いくつかのインダイレクション・モデルを提供します。
詳細は、7.1.3項「遅延ロードの使用」および7.2.1項「インダイレクション(遅延ロード)」を参照してください。
可変性とは、複雑なフィールドのプロパティの1つであり、フィールド値を(置換ではなく)変更できるかどうかを指定します。
不変マッピングでは、オブジェクトのオブジェクトIDが変更されないかぎり、つまり、オブジェクト値が別のオブジェクト値と完全に置換されないかぎり、マップされたオブジェクト値は変更できません。
可変マッピングでは、オブジェクトのオブジェクトIDを変更しなくても、マップされたオブジェクト値を変更できます。
デフォルトでは、EclipseLinkは次のように想定します。
すべてのTransformationMappingインスタンスは可変
すべてのJPA @Basicマッピング・タイプ(Serializableタイプは除く)は不変(DateおよびCalendarタイプを含む)
すべてのJPA @BasicマッピングのSerializableタイプは可変
値が不変か可変かは、アプリケーションによる永続クラスの使用方法に大きく依存します。たとえば、EclipseLinkは、デフォルトでDateタイプの永続フィールドを不変であると想定するため、フィールドの値が同じオブジェクトIDを持つかぎり、その値は変更されていないものとみなされます。アプリケーションでDateクラスのsetメソッドを使用する場合、そのオブジェクトIDを変更せずにDateオブジェクトの値の状態を変更できます。この場合、EclipseLinkでは変更が検出されません。これを回避するには、マッピングを可変として構成し、EclipseLinkに対して、オブジェクトIDのみではなく永続値の状態を調査するように指示します。
可変性を構成できる対象は次のとおりです。
TransformationMappingインスタンス
各JPA @Basicマッピング・タイプ(DateおよびCalendarタイプを含む)
すべてのDateおよびCalendarタイプ
可変性は、変更追跡のパフォーマンスに影響を与える場合があります。たとえば、トランスフォーメーション・マッピングが可変値をマップする場合、EclipseLinkは、作業ユニットで値をクローニングし、比較する必要があります。マッピングで単純な不変の値をマップする場合は、マッピングを不変として構成すると、作業ユニットのパフォーマンスを向上できます。
可変性は、ウィービングにも影響を与えます。EclipseLinkがウィービングを実行できるのは、不変マッピングの属性変更追跡ポリシーのみです。
詳細は、3.7項「ウィービングについて」を参照してください。『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』の@Mutable注釈の説明も参照してください。
EclipseLinkのメタデータは、アプリケーションの開発とデプロイされたランタイム環境の間の橋渡しをします。メタデータは次のものを使用して取得します。
注釈、persistence.xml、orm.xml、eclipselink-orm.xml、eclipselink-oxm.xml、および注釈とpersistence.xmlのプロパティ拡張機能。永続性プロバイダでは、これらすべてのメタデータのソースを解釈して、実行時にインメモリー・セッションおよびプロジェクトが作成されます。
JavaおよびEclipseLink API (この方法は最も労力が必要とされます)。
メタデータを通じて、構成情報をランタイム環境に渡すことができます。ランタイム環境では、永続クラス(Javaオブジェクトまたはエンティティ)およびEclipseLink APIを使用して記述されたコードとともにこの情報を使用して、アプリケーションが完成します。
詳細は、『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオーバーライドおよびマージに関する項を参照してください。
この項の内容は次のとおりです。
EclipseLinkメタデータ・アーキテクチャによって、次のような多くの重要な利点が提供されます。
ドメイン・モデル・オブジェクト内ではなく、XML内にマッピング情報を格納します。
メタデータを使用することにより、EclipseLinkはオブジェクト・モデルまたはデータベース・スキーマに介入しません。
開発者は、特定の設計を強引に通すことなく、必要に応じてオブジェクト・モデルを設計できるようになります。
DBAは、特定の設計を強引に通すことなく、必要に応じてデータベースを設計できるようになります。
コード生成(設計、実装、メンテナンスなどの重大な問題の原因になる可能性がある)に依存しません。
非介入型です。EclipseLinkに適合するようにオブジェクト・モデルまたはデータベース・スキーマを設計することを開発者に要求するのではなく、メタデータ自らがオブジェクト・モデルおよびデータベース・スキーマに適応します。
EclipseLink JPAを使用すると、標準のJPAの注釈、デプロイXMLまたはその両方を使用して永続性メタデータを柔軟に表現でき、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能もオプションで利用できます。
プロジェクトには、EclipseLinkランタイムがオブジェクトをデータ・ソースへマップするために使用するマッピング・メタデータが含まれています。プロジェクトは、EclipseLinkランタイムが使用するプライマリ・オブジェクトです。
この項では、プロジェクト・メタデータの最も重要な、次のような内容について説明します。
オブジェクト・リレーショナル・マッピングでは、EclipseLinkランタイムは、JPAの注釈、persistence.xml、orm.xml、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能の任意の組合せに基づき、インメモリー・プロジェクトを構成します。
Object-XMLマッピングでは、EclipseLinkランタイムは、JAXBの注釈とeclipselink-oxmバインディングの組合せを使用します。『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオーバーライドおよびマージに関する項を参照してください。
EclipseLinkは、開発者がJDeveloperで作成したディスクリプタとマッピングを使用して、アプリケーションの永続エンティティをデータベースにマップします。これらのツールは、次のプロジェクト開発へのアプローチをサポートします。
マッピング用のクラスと表のインポート
クラスのインポート、および表とマッピングの生成
表のインポート、およびクラスとマッピングの生成
クラス定義と表定義の作成
最も一般的なソリューションは、モデリング・ツールやJDeveloperのような統合開発環境(IDE)などの開発ツールを使用して永続エンティティを開発すること、および適切なリレーショナル設計ツールを使用してリレーショナル・モデルを開発することです。その後、開発者はJDeveloperを使用して、これら2つのモデルを関連付けるマッピングを作成します。
JDeveloperには、アプリケーションの永続エンティティまたはリレーショナル・モデル・コンポーネントを生成するための機能がいくつか用意されていますが、これらのユーティリティの目的はアプリケーションのラウンドトリップ開発を完了することではなく、短期間の初期開発方法を支援することのみです。
詳細は、第6章「ディスクリプタの理解」および第7章「マッピングの理解」を参照してください。
POJOプロジェクトの場合、データ・ソースへのアクセスに必要な情報を指定するセッション・メタデータでセッション・ログインを構成します。
詳細は、3.6.3項「セッション・メタデータの作成」を参照してください。
EclipseLinkセッションには、データ・ソースにアクセスするために必要な情報が含まれます。セッションは、EclipseLinkランタイムの機能にアクセスするためにアプリケーションが使用するプライマリ・オブジェクトです。
EclipseLinkランタイムは、EclipseLink JPAを使用して、JPAの注釈、persistence.xml、orm.xml、EclipseLink JPAの注釈およびpersistence.xmlのプロパティの拡張機能の任意の組合せに基づき、インメモリー・セッションを構成します。sessions.xmlファイルの使用はオプションです。『Oracle Fusion Middleware Oracle TopLink Java Persistence API (JPA)拡張機能リファレンス』のオーバーライドおよびマージに関する項を参照してください。
ウィービングは、コンパイル済のJavaクラスのバイトコードを操作する方法です。EclipseLinkのJPA永続性プロバイダでは、ウィービングを使用してJPAエンティティとPlain Old Java Object (POJO)クラスの両方を拡張し、遅延ロード、変更追跡、フェッチ・グループ、内部最適化などの操作に対応します。
ウィービングは、実行時(エンティティのロード時)に動的に実行するか、エンティティの.classファイルを後処理してコンパイル時に静的に実行できます。デフォルトでは、EclipseLinkは、Java EEアプリケーション・サーバーの内部やJava SE内(EclipseLinkエージェントが構成されている場合)などで、可能なかぎり動的ウィービングを使用します。動的ウィービングは構成しやすく、プロジェクトのビルド・プロセスを変更する必要がないので、動的ウィービングをお薦めします。
この項の内容は次のとおりです。
動的ウィービングを使用すると、アプリケーション・クラス・ファイルを実行時にロードする際に、1つずつウィービングできます。ウィービングするクラスの数がごく少ないか、クラスのウィービング時間が短い場合、このオプションを検討してください。
ウィービングするクラスの数が多いか、クラスのウィービング時間が長い場合は、静的ウィービングの使用を検討します。
静的ウィービングを使用すると、すべてのアプリケーション・クラス・ファイルをビルド時にウィービングして、事前ウィービング済のクラス・ファイルを配信できます。該当するすべてのクラス・ファイルのウィービングをビルド時に実行し、事前ウィービング済のクラス・ファイルを配信する場合に、このオプションの使用を検討してください。これを実行することで、動的ウィービングで必要とされる実行時のウィービング手順を省略して、アプリケーション・パフォーマンスを向上できます。
また、エージェントを構成できないJava環境でウィービングを実行する場合も、静的ウィービングの使用を検討してください。
EclipseLinkでは、POJOクラスで次の機能を有効にするためにウィービングを使用します。
遅延ロード
変更追跡
フェッチ・グループ
EclipseLinkでは、ウィービングを実行するPOJOアプリケーションをパッケージ化する際に、作成したJAR内のすべてのPOJOクラスのウィービングを実行します。
EclipseLinkでは、persistence.xmlファイルに定義されている次のすべてのクラスのウィービングを実行します。
persistence.xmlファイルにリストしたすべてのクラス
persistence.xmlファイルを含むJARに関連するすべてのクラス(要素<exclude-unlisted-classes>がfalseの場合)
EclipseLinkのデフォルトのウィービング動作は、EclipseLink JPA永続性プロバイダを使用するあらゆるJava EE JPA準拠アプリケーション・サーバーに適用されます。この動作を変更するには、JPAエンティティまたはPOJOクラスのpersistence.xmlファイルを変更し、EclipseLink JPAのプロパティ、EclipseLink JPAの注釈またはその両方を使用するように設定します。
EclipseLinkの永続性ユニット・プロパティを使用してウィービングを無効化するには、次の1つ以上のプロパティをfalseに設定してpersistence.xmlを構成します。
eclipse.weaving: すべてのウィービングを無効化します。
eclipselink.weaving.lazy: 遅延ロード(インダイレクション)のウィービングを無効化します。
eclipselink.weaving.changetracking: 変更追跡のウィービングを無効化します。
eclipselink.weaving.fetchgroups: フェッチ・グループのウィービングを無効化します。
eclipselink.weaving.internal: 内部最適化のウィービングを無効化します。
eclipselink.weaving.eager: 即時リレーションシップのインダイレクションのウィービングを無効化します。
