サービスファサードは通常、ステートレスセッションBeanとして実装されます。つまり、サービスファサードが返す可能性のあるエンティティは、すぐに切り離されます。これにより、サービスファサードビジネスメソッドの結果として返されるエンティティは、すべての内部を熱心にフェッチする必要があると思います。熱心なフェッチがない場合、サービスクライアントはその内部にアクセスできないためです。私はこれが正しいかどうか、そして特定の状況でより適切かもしれない他の方法があるかどうかを知りたいです。
ありがとうございました
はい、あなたは実質的に正しいです。エンティティは、データベースから作成またはフェッチされたセッションBeanメソッドから返されるとすぐに切り離されます。これは、クライアント層では、遅延ロードされた関連エンティティにアクセスする方法がないことを意味します。私の仕事の経験から、2つの一般的なシナリオがあると言えます。1つ目は、エンティティとエンタープライズBeanで実装されたビジネス層のデータモデルが、クライアント層で使用されているデータモデルとは完全に異なるものです。この場合の最善の解決策は、いわゆるDTO（データ転送オブジェクト）、つまりgetメソッドとsetメソッドを使用したプレーンJavaオブジェクトを作成し、それらを使用して2つのレイヤー間でデータを転送することです。このアプローチの主な欠点は、DTOの記述に時間がかかる可能性があることです。退屈でエラーが発生しやすいタスクであり、さらに、ビジネスロジックを実装していない、純粋なBeanである、またはロジックを両方の層で複製する必要があるという事実。これは、2つの層のデータモデルが同じで、1つが動作を再利用する場合に特に当てはまります。これは、ビジネス層とクライアント層で共有されるエンティティを使用して一意のデータモデルを構築するという、2番目のアプローチにつながります。これには、コードの記述とロジックの再利用が少ないという明らかな利点があります。ただし、切り離されたエンティティを1つのレイヤーから別のレイヤーに渡すには、2つの選択肢しかありません。すべての関係を熱心に宣言するか、エンティティが強力に相互接続されている場合は特にメモリにオブジェクトをロードしすぎるリスクがあるか、怠惰にして書き込みます。戻る前に必要なすべてのフィールドをロードするために、ファサードメソッドを慎重に使用してください。私'