DTOパターンは廃止されましたか？

Question

クラスタ化された完全なJava EEアプリケーションでは、DTOパターンは依然として有効なオプションですか？問題のアプリケーションでは、HibernateとStruts with SpringなどのEJBを使用します。このようなシナリオでは、ドメインオブジェクトの転送に問題はありますか？

編集：私の質問を明確にするために、現代のリソースとJava EEの改良により、ドメインオブジェクトを使用しない理由がありますか？存在しない場合は、DTOパターンの種類がフェードアウトしていないため、新しいアプリケーションでは使用しないでください。

Answer 1

廃止予定ではありません。 DTOパターンを使用するかどうかは、アプリケーションアーキテクチャに依存します。たとえば、Webサービス（JAX-WSまたはJAX-RSを使用）を開発する場合、C＃またはPythonクライアントアプリケーションがWebメソッドを使用してWebメソッドでDTOを送信する必要があります。 Hibernateのアノテーションは、他の言語よりもエンティティがそれらのアノテーションまたは他のビジネスロジックを使用して作成されないことを覚えておいてください。

---

EDIT（お客様のコメントに基づいています）：ソフトウェアアーキテクチャによって異なります。たとえば、私はSOAプロジェクトに取り組んでおり、サービス層とプレゼンテーション層にDTOを使用しています。より深いところでは、DTOを使用してサービス内のデータベース通信を処理したり、SPとの通信にSPのみを使用したりするため、Hibernateやその他のORMツールは使用できません。Spring DAOを使用でき、そのフレームワークもDTOを使用します。現在、多くのアプリケーションでDTOパターンが多数見つかります。この質問のために素晴らしいことだ

詳細情報：

は

• Difference between DTO, VO, POJO, JavaBeans?（基本的には、任意のDTOはPOJOです）。
• Core J2EE Patterns - Transfer Object

EDIT 2：DTOのデザインを使用するための主な理由を説明する情報の別のソースは、Martin Fowler

• LocalDTO

結論によって説明：DTOのではありませんアンチパターン。 DTOは、あるサブシステムから別のサブシステムにデータを渡す必要がある場合にのみ使用されるもので、通信するためのデフォルトまたは標準的な方法はありません。

Answer 2

パターンは純粋なデザインです。パターンの「廃止」はありませんが、時間の経過とともに使用量が少なくなります（または過剰使用）。
個人的には、なぜDTOを使用しないのか分かりません。
たとえば、oVirtオープンソースプロジェクトでは、仮想化ドメインにビジネスロジックエンティティを表すエンティティがあります。
これらのエンティティは、Hibernateアノテーションで注釈を付けるか（実際には、Hibernate POCで作業を開始した今日のものです）、DTOとしての役割を果たすようにしてから、マップされるアノテーションオブジェクトからきれいにしてください（dozerクライアントに渡されたクライアントオブジェクト（値オブジェクト）として機能する必要があります。また、他のクラスは、クライアントとして使用する必要があります（クライアント側コードで不要な注釈があるのは嫌いです）。 DTOエンティティ

上記アプローチのマイナスは、2つの並列クラスダイアグラム（DTO用とクライアント用のバリューオブジェクト用）があるかもしれないということですが、設計上の多くの場合、オフ。
あなたは長所と短所を理解し、何が最善のものかを理解する必要があります（私たちの場合、クライアント側はGWTなので、2つのクラス階層、つまりDTO /サーバー側さらに多くのサーバサイドアノテーションだけで注釈を付けることができ、もう1つはGWTクライアントコードに送信されます）。

Answer 3

これはJava EEで非常に便利なパターンです。

DTOを使用して、関連するエンティティオブジェクトをEJB BeanからUIレイヤーに転送します。エンティティオブジェクトは、（TransactionAttributeType.REQUIRED参照）のトランザクションでDB からフェッチされ、DTOオブジェクトに格納されます。 DTOはUIレイヤでであり、消費されるのはです。