回答:
データ転送オブジェクトは、データをカプセル化し、アプリケーションのサブシステム間で送信するために使用されるオブジェクトです。
DTOは、N層アプリケーションのサービス層で最もよく使用され、それ自体とUI層の間でデータを転送します。ここでの主な利点は、分散アプリケーションでネットワークを介して送信する必要があるデータの量が減ることです。また、MVCパターンで優れたモデルを作成します。
DTOのもう1つの用途は、メソッド呼び出しのパラメーターをカプセル化することです。これは、メソッドが4つまたは5つを超えるパラメーターを取る場合に役立ちます。
DTOパターンを使用する場合は、DTOアセンブラも使用します。アセンブラは、ドメインオブジェクトからDTOを作成するために使用され、その逆も同様です。
ドメインオブジェクトからDTOへの変換とその逆の変換は、コストのかかるプロセスになる可能性があります。Martin Fowlerがここで説明するように、分散アプリケーションを作成していない場合は、パターンから大きなメリットが得られないでしょう。
DTOの定義は、Martin Fowlerのサイトにあります。DTOは、パラメーターをメソッドに転送するため、および戻り値の型として使用されます。多くの人々はUIでそれらを使用しますが、他の人々はそれらからドメインオブジェクトを膨らませます。
DTOはばかげたオブジェクトです。プロパティを保持し、ゲッターとセッターを持っていますが、（compare（）またはequals（）実装以外の）重要なロジックはありません。
通常、MVCのモデルクラス（ここでは.net MVCと想定）はDTO、またはDTOのコレクション/集合体です
一般に、値オブジェクトは不変である必要があります。以下のような整数や文字列は Javaでオブジェクト。これらを使用して、ソフトウェアレイヤー間でデータを転送できます。マイクロサービス環境やレガシーJavaエンタープライズアプリなど、さまざまなリモートノードでソフトウェアレイヤーまたはサービスが実行されている場合。2つのクラスのほぼ正確なコピーを作成する必要があります。ここがDTOに出会った場所です。
|-----------| |--------------|
| SERVICE 1 |--> Credentials DTO >--------> Credentials DTO >-- | AUTH SERVICE |
|-----------| |--------------|
レガシーJava Enterprise Systemsでは、DTOにさまざまなEJB要素を含めることができます。
これがベストプラクティスであるかどうかはわかりませんが、Spring MVC / Bootプロジェクトで個人的に次のようにValueオブジェクトを使用しています。
|------------| |------------------| |------------|
-> Form | | -> Form | | -> Entity | |
| Controller | | Service / Facade | | Repository |
<- View | | <- View | | <- Entity / Projection View | |
|------------| |------------------| |------------|
コントローラー層はエンティティが何であるかを知りません。フォームおよびビュー値オブジェクトと通信します。フォームオブジェクトにはJSR 303検証アノテーション（@NotNullなど）があり、ビュー値オブジェクトにはカスタムシリアル化のためのジャクソンアノテーションがあります。（たとえば、@ JsonIgnore）
サービス層は、エンティティオブジェクトを使用してリポジトリ層と通信します。Entityオブジェクトには、JPA / Hibernate / Spring Dataアノテーションが付いています。すべての層は下位層のみと通信します。循環/循環依存のため、層間通信は禁止されています。
User Service ----> XX CANNOT CALL XX ----> Order Service
一部のORMフレームワークには、追加のインターフェースまたはクラスを使用して投影する機能があります。そのため、リポジトリはViewオブジェクトを直接返すことができます。追加の変換は必要ありません。
たとえば、これはユーザーエンティティです。
@Entity
public final class User {
private String id;
private String firstname;
private String lastname;
private String phone;
private String fax;
private String address;
// Accessors ...
}ただし、id、firstname、lastnameのみを含む、ページ分割されたユーザーのリストを返す必要があります。次に、ORMプロジェクションのビュー値オブジェクトを作成できます。
public final class UserListItemView {
private String id;
private String firstname;
private String lastname;
// Accessors ...
}リポジトリレイヤーからページ分割された結果を簡単に取得できます。Springのおかげで、投影にインターフェースのみを使用することもできます。
List<UserListItemView> find(Pageable pageable);他の変換操作BeanUtils.copyメソッドがうまく機能することを心配しないでください。
GET/ POST/ whatever）エンドポイントを呼び出すか、SOAを使用してWebサービスを使用するなど）、必要のないコードで大きなサイズのオブジェクトを送信したくないエンドポイントはデータを消費し、転送を遅くします。DefN
DTOはハードコードされたデータモデルです。すべてのフィールドがコンパイル時に認識されているため、厳密に型指定されたプロパティを介してアクセスされる、ハードコードされた生産プロセスによって処理されるデータレコードのモデリングの問題のみを解決します。
対照的に、動的モデルまたは「プロパティバッグ」は、実行時に生産プロセスが作成されるときのデータレコードのモデリングの問題を解決します。
Cvar
DTOはフィールドまたはプロパティでモデル化できますが、誰かがCvarと呼ばれる非常に便利なデータコンテナを発明しました。値への参照です。参照プロパティと呼ばれるものを使用してDTOをモデル化すると、ヒープメモリを共有するようにモジュールを構成して、共同で作業することができます。これにより、パラメーターの受け渡しとO2O通信がコードから完全に排除されます。つまり、参照プロパティを持つDTOを使用すると、コードでゼロカップリングを実現できます。
class Cvar { ... }
class Cvar<T> : Cvar
{
public T Value { get; set; }
}
class MyDTO
{
public Cvar<int> X { get; set; }
public Cvar<int> Y { get; set; }
public Cvar<string> mutableString { get; set; } // >;)
}
出典：http : //www.powersemantics.com/
動的DTOは、動的ソフトウェアに必要なコンポーネントです。動的プロセスをインスタンス化するための1つのコンパイラステップは、スクリプト内の各マシンを、スクリプトが定義する参照プロパティにバインドすることです。動的DTOは、Cvarをコレクションに追加することによって構築されます。
// a dynamic DTO
class CvarRegistry : Dictionary<string, Cvar> { }
競合
注：Wixはパラメーターを編成するためのDTOの使用を「アンチパターン」としてラベル付けしたため、私は権威ある意見を述べます。
return View(model); // MVC disagrees
私の協調アーキテクチャは、設計パターンを置き換えます。私のウェブ記事を参照してください。
パラメータは、スタックフレームマシンの即時制御を提供します。継続的な制御を使用するため、即時制御が不要な場合、モジュールにパラメーターは必要ありません。私のアーキテクチャには何もありません。マシン（メソッド）のインプロセス構成は、パラメーターが値タイプである場合、複雑さだけでなく値（パフォーマンス）も追加します。ただし、参照型パラメーターを使用すると、コンシューマーはキャッシュミスによってヒープから値を取得できます。したがって、参照プロパティを使用してコンシューマーを構成します。機械工学の事実：処理（コンポーネントの作成）自体が無駄であるため、パラメータへの依存は一種の事前最適化です。詳細については、私のWの記事を参照してください。http://www.powersemantics.com/w.html。
Fowlerと会社は、他のアーキテクチャーを知っていた場合、分散アーキテクチャー以外のDTOの利点を理解するかもしれません。プログラマーは分散システムしか知りません。統合コラボレーティブシステム（別名、製造、別名、製造）は、私がこの方法でコードを記述した最初の人なので、自分のアーキテクチャとして主張しなければならないものです。
一部の人は、DTOを貧血ドメインモデルと見なします。つまり、DTOは機能を欠いていますが、これは、オブジェクトが相互作用するデータを所有する必要があることを前提としています。この概念モデルでは、オブジェクト間でデータを配信する必要があります。これは、分散処理のモデルです。ただし、製造ラインでは、各ステップは最終製品にアクセスして、所有または制御することなく変更できます。これが、分散処理と統合処理の違いです。製造は、製品を運用および物流から分離します。
電子メールの追跡を維持せずに相互に電子メールで作業する無駄なオフィスワーカーの集まりとしてのモデリング処理には、本質的に何も問題はありません。適切にモデル化された分散プロセスは、製品にどの操作が行われ、どの操作が行われるかを記述したドキュメント（アクティブルーティング）を添付します。アクティブなルーティングは、プロセスの開始前に書き込まれるプロセスのソースルーティングのコピーです。欠陥またはその他の緊急の変更が発生した場合、アクティブなルーティングは、送信先の操作ステップを含むように変更されます。これにより、生産に費やされたすべての労働力が明らかになります。