クラスター化された完全な Java EE アプリケーションでは、DTO パターンは依然として有効なオプションですか? 問題のアプリケーションは、EJB の Hibernate と Struts を Spring などで使用しています。このようなシナリオでドメイン オブジェクトを転送することに問題はありますか?
編集:私の質問を明確にするために、現代のリソースとJava EEの改善により、ドメインオブジェクトを使用しない理由はありますか? そうでない場合、DTO パターンは一種のフェードアウトではなく、新しいアプリケーションで使用すべきではありませんか?
非推奨ではありません。DTOパターンを使用するかどうかは、アプリケーションアーキテクチャによって異なります。たとえば、（JAX-WSまたはJAX-RSを使用して）Webサービスを開発する場合、C＃またはPythonクライアントアプリケーションがDTOを使用できるように、Webメソッドを介してDTOを送信する必要があります。また、Webメソッドは、クラスが持つオブジェクトを返さないようにする必要があります。 Hibernateアノテーション、他の言語よりもエンティティはそれらのアノテーションまたは他のビジネスロジックを内部に使用して作成されないことを覚えておいてください。
編集（あなたのコメントに基づく）：それはソフトウェアアーキテクチャに依存します。たとえば、私はSOAプロジェクトに取り組んでおり、サービス層とプレゼンテーション層にDTOを使用しています。さらに深く、サービス内のデータベース通信を処理するためにDTOを使用し、DBとの通信にSPのみを使用するため、Hibernateやその他のORMツールはそこで機能できず、Spring DAOを使用でき、そのフレームワークもDTOを使用します。最近の多くのアプリケーションで多くのDTOパターンを見つけることができます。
この質問に最適な詳細情報：
編集2：マーティンファウラーによって説明された、DTOの設計を使用する主な理由を説明する別の情報源
結論：DTOはアンチパターンではありません。DTOは、あるサブシステムから別のサブシステムにデータを渡す必要があり、通信するためのデフォルトまたは標準の方法がない場合にのみ使用することを目的としています。
これは、JavaEEで非常に便利なパターンです。
DTOを使用して、関連するエンティティオブジェクトをEJBBeanからUIレイヤーに転送します。エンティティオブジェクトは、1つのトランザクションでDBからフェッチされ（TransactionAttributeType.REQUIREDを参照）、DTOオブジェクトに格納されます。DTOはUIレイヤーで使用されます。
パターンは純粋なデザインです。パターンの「非推奨」はありませんが、時間の経過とともに使用量が減ります (または過剰使用)。
個人的には、DTO を使用しない理由がわかりません。
たとえば、oVirtオープン ソース プロジェクトでは、仮想化のドメインにビジネス ロジック エンティティを表すエンティティがあります。
これらのエンティティは、Hibernate アノテーションでアノテーションを付けて (実際には、Hibernate POC の作業を開始したので、今日です)、DTO として機能し、それらにマップされるアノテーション オブジェクトからクリーンにする必要があります (たとえば、ドーザーフレームワークを使用します) 。クライアントによって使用されます
(不要な注釈を含むクライアント側のコードは好きではありません)、またはエンティティはクライアントに渡されるクライアント オブジェクト (値オブジェクト) として機能する必要があり、他のクラスは DTO エンティティとして機能する必要があります
。上記のアプローチのマイナス点1 つは DTO 用で、もう 1 つは値オブジェクト (クライアントによって使用される) 用ですが、多くの場合、設計ではトレードオフがあります。
長所と短所を理解し、自分に最適なものを選択する必要があります (この場合、クライアント側は GWT であるため、DTO/サーバー側である 2 つのクラス階層に分離する方が簡単です。また、より多くのサーバー側のみの注釈で注釈が付けられ、もう一方は GWT クライアント コードに送信されます)。