ガイドライン: エンティティー Bean の識別
トピック
概論
このガイドラインでは、エンティティー Bean の識別を中心に説明します。エンティティー Bean に関する補足ガイダンスは、『ガイドライン: エンティティー Bean』で提供します。EJB に関する一般的なガイダンスは、『ガイドライン:
Enterprise JavaBeans (EJB)』で提供します。
エンティティー Bean の識別
エンティティー Bean は永続データを扱うので、多くの場合、エンティティー分析クラス (『成果物: 分析クラス』を参照) に非常に適しています。エンティティー Bean は、永続状態を含むビジネス・エンティティーに対応します。
また、ビジネス・エンティティー固有の論理を実装するサービスを提供します。エンティティー Bean の別の特性として、同時に複数のクライアントにサービスを提供できることが挙げられます。EJB コンテナーは、このようなクライアントとトランザクションを調整します。
エンティティー Bean は、永続性の提供に使用されますが、ビジネス論理のカプセル化もできます。一般に、エンティティー Bean は、エンティティー Bean によって永続化されたデータに関連するビジネス論理と、依存する任意のデータ・オブジェクトのみを含む必要があります。一般に、エンティティー Bean の内部論理は、エンティティー Bean どうしの結合が最小になるように取り出してセッション Bean に入れる必要があります。
エンティティー Bean のモデリング
『ガイドライン: Enterprise JavaBeans (EJB) の識別』を参照してください。
粒度
粒度は、エンティティー EJB で表現されるデータのサイズを意味します。適切な粒度は、使用する EJB 仕様のバージョンによって異なります。
EJB 2.0 より前、エンティティー EJB では常に大きな粒度が推奨されていました。複数データベース・テーブルをグループ化したデータを大きな単位でまとめることも一般的でした。これは、各エンティティー EJB によって重大なオーバーヘッドが生じていたことが原因です。特に、リモートで使用できるようにするためのオーバーヘッドです。例えば、請求書の明細項目やスプレッドシートのセルは、あまりにも粒度が小さいので、ネットワーク経由で頻繁にアクセスするべきではありません。反対に、請求書の入力を論理的にグループ化したものや、スプレッドシートのセルのサブセットであれば、データに追加のビジネス論理が必要な場合に、エンティティー EJB としてモデリングできました。
この点が、EJB 2.0 で若干変更されました。ローカル・インターフェースの導入によって、 これらのオーバーヘッドがいくらか低減し、より粒度の小さいオブジェクトを EJB としてモデリングできます。ローカルおよびリモートのインターフェースは、『概念:
J2EE の概要: Enterprise JavaBeans』で説明されています。ローカル・インターフェースには、リモート・インターフェースに該当するオーバーヘッドはなく、緊密に結合した Bean の効率的な相互作用が実現します。ローカル・インターフェースは、部品の作成と破棄を行う大規模なエンティティーを構成する粒度の小さいエンティティーに使用すると特に有効です。クライアントが、大規模なエンティティーのリモート・インターフェースを使用すると、その結果、大規模なエンティティーは、その部品と相互作用するローカル・インターフェースを使用します。
それでも、エンティティー Bean が別のクラスに対するコンポジション関係を持つ場合、そのクラスを、エンティティー Bean ではなく通常の Java クラスとしてモデリングする選択もあります。コンテナー管理による持続性を使用する場合、そのような Java クラスは、「従属値クラス」として参照されます。従属値クラスは、エンティティー Bean よりも簡単で迅速に開発とテストが行え、構成されたクラスがエンティティー Bean の機能を必要としない場合は、適切な選択です。従属値クラスには、次の制限があります。
- エンティティー Bean 参照を含むことができません。
- 値による "get" および "set" を行うため、性能上のコストがかかりますが、リモート・インターフェース経由のアクセスを可能にします。
カプセル化
エンティティー EJB に対応するビジネス・エンティティーの操作用の論理インターフェースを提供するために、関連するエンティティー Bean をセッション Bean ファサードでラッピングすることを検討してください。『ガイドライン: セッション Bean の識別』を参照してください。
同様のアプローチとして、1 つのエンティティー Bean がほかの (通常は依存している) ローカル・エンティティー Bean のセットをカプセル化する方法もあります。リモート・クライアントは、「メイン」のエンティティー Bean を介してすべてのデータにアクセスします。「Core J2EE Patterns - Composite Entity Pattern」 (参考資料 ALU01)
に、この代替の方法が説明されています。ただし、エンティティー Bean の関係をより簡単に管理するメソッドとして、セッション Bean ファサードが推奨されています。
|