DTO（データ転送オブジェクト）を使用する意味は何ですか？

132

DTOを使用する意味は何ですか？それは時代遅れの概念ですか？ビューレイヤーでPOJOを使用して、データを転送および永続化します。これらのPOJOはDTOの代替と見なすことができますか？

java design-patterns

10

ただし、POJOはDTOであり、DTOはPOJOで実装できます。あなたは比較に値するリンゴとオレンジです。

— 陶酔

3

良いアイデアが時代遅れになるのはなぜですか？Lispを見てください。冗談は別として、私はEuphoricに同意します。私は通常、POJOを使用してDTOを実装します。DTOは非常にシンプル（KISS）で便利な概念であることに変わりはありません。

— ジョルジオ

意味がありません。アンチパターンです。データ転送オブジェクトは恥です

— -yegor256

115

DTOはパターンであり、実装（POJO / POCO）に依存しません。DTOによれば、リモートインターフェイスへの各呼び出しは高価なので、各呼び出しへの応答は可能な限り多くのデータをもたらす必要があります。そのため、特定のタスクのデータを取得するために複数の要求が必要な場合、1つの要求だけで必要なすべてのデータを取得できるように、取得するデータをDTOで組み合わせることができます。エンタープライズアプリケーションアーキテクチャのパターンのカタログに詳細があります。

DTOは基本的な概念であり、時代遅れではありません。

— theD
ソース

9

誰もがこれらの日車輪の再発明ているように見えるので、あなたは、しかし別の名前の下でそれらを見つけること

— linkerro

3

「値オブジェクト」に似ています。

— theD

2

@linkerro：True：多くの人は、自分自身で再発明するのではなく、すでに発明されたものについて読むのにもっと時間を費やすべきだと思います。再発明されたものは常に成熟度が低くなります。

— ジョルジオ

10

@Giorgio多くの開発者がまだ着手してはいけないアイデアで走っています。開発者が読んだすべてのアイデアに疑問を呈したいと思います。

— エリックReppen

59

概念としてのDTO（サーバーがクライアントに返すデータを収集することを目的とするオブジェクト）は、確かに時代遅れではありません。

何でやや時代遅れすると、まったくのロジックを含んでいないのDTOを持つという考え方で、使用されているだけのデータを送信するために、クライアントに送信される前に、ドメインオブジェクトから「マッピング」、および表示層に渡す前にモデルを表示するためにそこにマッピングされます。単純なアプリケーションでは、ドメインオブジェクトをDTOとして直接再利用し、ディスプレイレイヤーに直接渡すことができるため、統一されたデータモデルは1つだけです。より複雑なアプリケーションでは、ドメインモデル全体をクライアントに公開したくないため、ドメインモデルからDTOへのマッピングが必要です。DTOからのデータを複製する別のビューモデルを使用することはほとんど意味がありません。

ただし、この概念が単なる間違っているのではなく時代遅れである理由は、一部の（主に古い）フレームワーク/テクノロジーがそれを必要とするためです。ドメインモデルとビューモデルはPOJOSではなく、フレームワークに直接結び付けられているためです。

最も注目すべきは、EJB 3標準以前のJ2EEのEntity BeanはPOJOではなく、アプリサーバーによって構築されたプロキシオブジェクトでした。単にクライアントに送信することは不可能だったため、別のDTOレイヤーを作成することはできませんでした-それは必須でした。

— マイケル・ボルグワード
ソース

2

UI開発者がよりジェネラリストの役割を余儀なくされたため、コードベースでMapper.Map現象が明らかになることは間違いありません。DTOがそれ自体をマップできないのはなぜですか？

— エリックReppen

1

@ErikReppen主な利点は、ドメインモデルとDTOを分離することです。DTOがそれ自体をマップする場合、ドメインモデルへの参照が必要です。

— アレクサンダーダーク

17

DTOは時代遅れのパターンではありませんが、不必要に適用されることが多く、時代遅れに見えるかもしれません。

Java Enterpriseコミュニティで最も誤用されているパターンはDTOです。DTOは、配布の問題の解決策として明確に定義されました。DTOは、プロセス（層）間でデータを効率的に転送する、粒度の粗いデータコンテナになることを目的としていました。〜アダム・ビエン

たとえば、JSF ManagedBeanがあるとします。よくある質問は、BeanがJPAエンティティへの参照を直接保持するのか、または後でエンティティに変換される中間オブジェクトへの参照を保持するのかです。この中間オブジェクトはDTOと呼ばれますが、ManagedBeanとエンティティが同じJVM内で動作している場合、DTOパターンを使用するメリットはほとんどありません。

Bean Validation注釈を検討してください。JPAエンティティには、@ NotNullおよび@Size検証で注釈が付けられている可能性があります。DTOを使用している場合は、リモートインターフェイスを使用しているクライアントが基本的な検証に失敗したことを確認するためにメッセージを送信する必要がないように、DTOでこれらの検証を繰り返します。DTOとエンティティ間でBean Validation注釈をコピーする余分な作業を想像してください。ただし、ビューとエンティティが同じJVM内で動作している場合、この余分な作業を行う必要はありません。エンティティを使用するだけです。

エンタープライズアプリケーションアーキテクチャのパターンのカタログへのIAmTheDudeのリンクは、DTOの簡潔な説明を提供します。

— デビッドS
ソース

3

「...、しかし、ManagedBeansとEntitiesが同じJVM内で動作している場合、DTOパターンを使用するメリットはほとんどありません」という文があります。世の中には多くの中規模のアプリがありますが、これらのアプリは何の利益もなく馬鹿げてDTOパターンを実装しています。無駄な「コピー層」を追加するだけです。これらのシステムを作成した人々は、トランザクションの終了時にJava EE 5+エンティティマネージャーがエンティティを切り離し、それらを実際のDTOにすることに気づきませんでした。そのため、単一JVM Webアプリケーションの場合、パターンの種類は時代遅れです。J2EEバックエンドの開発者の遺物のようです...

— Kawu

しかし、「JSF ManagedBean」および「JPA Entity」とは何ですか？それらが時代遅れでなければ、フレームワークと言語にとらわれない用語を使用してそれらを説明できるはずです。

— Uアバロス

8

絶対違う！つい最近、使用するビジネスオブジェクト（ORMマッパーにバインドされている可能性があります）よりも、DTOを使用する方が良いという教訓を学びました。

ただし、適切なパターンブックで言及されているため、使用するためだけでなく、使用するのに適切な場合にのみ使用してください。
私の頭に浮かぶ典型的な例は、ある種のインターフェースをサードパーティに公開するときです。このようなシナリオでは、交換されたオブジェクトを非常に安定した状態に保ちたいので、通常はDTOでうまく実現できます。

— ジュリ
ソース

1

DTOが特に役立つとわかった1つの場所は、API応答のロジックを含めることです。このパターンを使用すると、オブジェクトからさまざまな形式へのさまざまな種類の応答をテスト可能な方法で簡単に管理できます。私の現在の役割でこのパターンを使用して、APIの応答形式のテストを開始することができました。これは、スタックがさまざまなクライアント（http / mobile）と同形になっているため、貴重でした。間違いなく時代遅れではありません。

— ズキンタナ
ソース