DTO（データ転送オブジェクト）を使用するポイントは何ですか？
[〜＃〜] dto [〜＃〜] を使用する目的は何ですか？それは古い概念ですか？ビューレイヤーで [〜＃〜] pojo [〜＃〜] sを使用して、データを転送および永続化します。これらのPOJOはDTOの代替と見なすことができますか？
DTOはパターンであり、実装（POJO/POCO）に依存しません。 DTOによると、リモートインターフェースへの呼び出しはそれぞれに費用がかかるため、各呼び出しへの応答は可能な限り多くのデータをもたらすはずです。したがって、特定のタスクのデータを取得するために複数の要求が必要な場合、1つの要求だけで必要なすべてのデータを取得できるように、取得するデータをDTOで組み合わせることができます。 エンタープライズアプリケーションアーキテクチャのパターンのカタログ に詳細があります。
DTOは基本的な概念であり、古くはありません。
概念としてのDTO（サーバーからクライアントに返されるデータを収集することを目的とするオブジェクト）は時代遅れではありません。
何がisロジックがまったく含まれていないDTOがあるという概念ですonlyはデータを送信するために使用され、クライアントに送信する前にドメインオブジェクトから「マッピング」されます。そして、表示レイヤーに渡す前に、ビューモデルにマッピングされます。単純なアプリケーションでは、多くの場合、ドメインオブジェクトを直接DTOとして再利用し、直接ディスプレイレイヤーに渡すことができるため、1つの統合データモデルしか存在しません。より複雑なアプリケーションでは、ドメインモデル全体をクライアントに公開したくないため、ドメインモデルからDTOへのマッピングが必要です。 DTOからのデータを複製する別のビューモデルを用意することは、ほとんど意味がありません。
ただし、この概念が明らかに間違っているのではなく時代遅れである理由は、一部の（主に古い）フレームワーク/テクノロジーがドメインとビューモデルがPOJOSではなく、代わりにフレームワークに直接結び付けられているため、これを必要とするためです。
特に注目すべきは、EJB 3標準以前のJ2EEのエンティティBeanはPOJOではなく、代わりにアプリサーバーによって構築されたプロキシオブジェクトでした。これらをクライアントに送信することは単に不可能だったため、個別のDTOレイヤーを使用することはできませんでした。 -それは必須でした。
DTOは古くなったパターンではありませんが、しばしば不必要に適用されるため、古く見える場合があります。
Java達人アダムビーンから：
Javaエンタープライズコミュニティで最も誤用されているパターンはDTOです。DTOは、配布の問題の解決策として明確に定義されています。DTOは、データを効率的に転送する粗粒度のデータコンテナーであることが意図されていましたプロセス（層） 〜Adam Bien
マーティン・ファウラーから：
DTOは、データ転送オブジェクトと呼ばれます。その目的は、高価なリモート呼び出しでデータをシフトすることです。これらは、リモートインターフェイスがパフォーマンスのために必要とする粗いインターフェイスの実装の一部です。ローカルコンテキストでそれらを必要としないだけでなく、粗粒度のAPIの使用がより難しく、ドメインまたはデータソースレイヤーからDTOにデータを移動するすべての作業を行う必要があるため、実際には有害です。 〜マーティンファウラー
以下は、Java EEの一般的なEEの具体例ですが、正しくありませんDTOパターンの使用です。 Java EEの場合、MVCパターンを知る必要があります。「JSF ManagedBean」はビューで使用されるクラスであり、「JPAエンティティ」はMVCパターンのモデルです。
たとえば、JSF ManagedBeanがあるとします。よくある質問は、BeanがJPAエンティティへの参照を直接保持する必要があるのか、または後でエンティティに変換される中間オブジェクトへの参照を維持するのかということです。 DTOと呼ばれるこの中間オブジェクトを聞いたことがありますが、ManagedBeanとエンティティが同じJVM内で動作している場合、DTOパターンを使用してもほとんどメリットがありません。
さらに、Bean Validationアノテーションを検討してください（ここでも、Java EEに慣れていない場合は、Bean Validationがデータを検証するためのAPIであることを知ってください）。JPAエンティティには@NotNullおよび@サイズの検証。DTOを使用している場合は、DTOでこれらの検証を繰り返して、リモートインターフェイスを使用しているクライアントがメッセージを送信して基本的な検証が失敗したことを確認する必要がないようにする必要があります。 DTOとエンティティの間でBean Validationアノテーションをコピーするという追加の作業が必要ですが、ビューとエンティティが同じJVM内で動作している場合は、この追加の作業を行う必要はありません。エンティティを使用するだけです。
IAmTheDudeの エンタープライズアプリケーションアーキテクチャのパターンのカタログ へのリンクは、DTOの簡潔な説明を提供します。
絶対違う！ごく最近、私は DTOのより良い使用について学んだレッスン 使用するビジネスオブジェクトではなく（おそらくORMマッパーにバインドされています）。
ただし、適切なパターンブックに記載されているため、使用する目的だけでなく、適切な場合にのみ使用してください。
ちょうど私の頭に浮かぶ典型的な例は、ある種のインターフェースをサードパーティに公開するときです。このようなシナリオでは、交換されたオブジェクトを非常に安定した状態に保ち、通常はDTOを使用して適切に達成できます。
DTOが特に役立つことがわかった1つの場所は、API応答のロジックを含めることです。このパターンを使用すると、オブジェクトからさまざまな形式へのさまざまな種類の応答をテスト可能な方法で簡単に管理できます。私の現在の役割でこのパターンを使用すると、スタックがさまざまなクライアント（http /モバイル）でより同型になったため、APIの応答フォーマットのテストを開始することができました。間違いなく時代遅れではありません。