1

私は、データベース（MySQL）、永続性（JPA）、ビジネス（EJBのステートレスセッションBeanに似たPOJO）、プレゼンテーション（Java Swing）の4つの層でJavaアプリケーションを開発しています。

プレゼンテーション層と永続性層を完全に分離することにしました。したがって、すべてのデータに対するすべての変更は、ビジネス層を介して行われます。このように、プレゼンテーション層はエンティティクラスが存在することさえ知りません。これにより、セッションBeanは、エンティティを変更する前にプレゼンテーションから受け取った値を検証または変換する必要がある場合があるため、渡されるデータをより適切に制御できます。

ただし、セッションBeanは、大量の情報（多くのプロパティを持つエンティティのリストなど）を呼び出し元に送信する必要がある場合があります。そして、これは複雑になります。これは、セッションBeanを採用した設計によれば、これらすべてのエンティティを別のエンティティにアンラップする必要があるためです。エンティティのリストを配列のリスト（配列の各メンバーがエンティティのプロパティに対応している）に変換しようとしましたが、これは非常に欠陥があり、エラーが発生しやすく、非効率的です。

プレゼンテーションにデータを送信する正しい方法は何でしょうか？セッションBeanの背後にエンティティを隠すという概念はまったく意味がありますか？そのようなアプリケーションの一般的なパターンは何ですか？

4

2 に答える 2

2

一般的なパターンは、JPAエンティティが請求に適合する場合（つまり、プレゼンテーション層に必要なデータが含まれている場合、およびこのデータを返すためにデータベースの半分をフェッチする必要がない場合）、およびDTOを使用することです。 （データ転送オブジェクト。必要な情報を含むPOJOにすぎません）エンティティが法案に適合しない場合。

あなたがしているように、DTOのみを使用することを好む人もいます。ただし、DTOは、型指定されたプロパティを持つ実際のオブジェクトである必要があります。配列のリストは、理解して維持するのが悪夢であり、型の安全性とコンパイルチェックを提供せず、一般にJavaBeansを期待する従来のプレゼンテーション層テクノロジ（JSP ELなど）では簡単に使用できません。

于 2012-06-19T11:08:25.217 に答える
1

セッションBeanの背後にエンティティを隠すという概念はまったく意味がありますか？そのようなアプリケーションの一般的なパターンは何ですか？

はい、クライアントが別のJVM（リモート）で実行されている場合は、JPAエンティティの代わりにDTO（デザインパターン;データ転送オブジェクト）を送信することをお勧めします。

おそらく探しているEJBデザインパターンは次のとおりです。サービスファサード目標は、粗粒度のクライアント/ユースケース固有のAPIを提供することです。

Adam Bienは、Java EE 5/6デザインパターンに関する本を書きました：http： //press.adam-bien.com/real-world-java-ee-patterns-rethinking-best-practices.htm

フィルタリングやページング技術など、ユーザーが便利に処理できる量のデータのみを送信します。

于 2012-06-19T11:05:43.250 に答える