DTO = ViewModel？

NHibernateを使用してドメインオブジェクトを永続化しています。物事をシンプルに保つために、ASP.NET MVCプロジェクトをプレゼンテーションレイヤーとサービスレイヤーの両方として使用しています。

コントローラークラスからドメインオブジェクトをXMLで返したいのですが。Stack Overflowのいくつかの投稿を読んだ後、DTOを収集します。ただし、ViewModelについての投稿もありました。

私の質問：データ転送オブジェクトとViewModelは同じものですか？それともViewModelはDTOのサブパターンの一種ですか？

DTOの標準的な定義は、動作のないオブジェクトのデータ形式です。

ViewModelsはビューのモデルです。ViewModelは通常、1つ以上のオブジェクト（またはDTO）からの完全または部分的なデータと、ビューの動作に固有の追加のメンバー（ビューによって実行できるメソッド、ビュー要素を切り替える方法を示すプロパティなど）です。ビューとビヘイビアーのすべてのデータとしてビューモデルを見ることができます。ViewModelは、1対1でビジネスオブジェクトまたはDTOにマップする場合としない場合があります。

ちなみに、NHibernate プロジェクションは、特定のビューモデルが永続化オブジェクトからのデータのサブセットを必要とする場合に便利です。

ASP.NET MVCのViewModelはDTOと同じですが、MVVMのViewModelには動作がありますが、DTOにはないため、MVVMパターンのViewModelはDTOとは異なります。

DTO！= ViewModel

でMVVMのパターンのViewModelはビューからモデルを分離するために使用されます。モデルを表すには、NHibernateなどを介してデータベースに再度マッピングされる単純なDTOクラスを使用できます。しかし、DTOとしてモデル化されたViewModelクラスを見たことがありません。ViewModelクラスには、DTOにはない動作がほとんどあります。

DTO-データ転送オブジェクトは、データを転送するためのコンテナーです。それらには振る舞いはありませんが、セッターとゲッターの束だけです。一部の人々はそれらを不変にし、既存のものを更新するのではなく、必要に応じて新しいものを作成します。それらは、回線を介した転送を可能にするためにシリアライズ可能でなければなりません。

リモートサービスへの呼び出しは高額になる可能性があるため、必要なすべてのデータがDTOにプッシュされ、1つのチャンク（粗い粒子）でクライアントに転送されるため、通常、DTOはプロセス境界を越えて1つのレイヤーから別のレイヤーにデータを送信するために使用されます。

ただし、画面にバインドされたDTOの概念を使用する人もいます（プロセス境界を越えることとは関係ありません）。繰り返しになりますが、これらには必要なデータ（通常、特定の画面に必要なデータであり、さまざまなソースからのデータの集約である可能性があります）が入力され、クライアントに送信されます。

http://blog.jpboodhoo.com/CommentView,guid,21fe23e7-e42c-48d8-8871-86e65bcc9a50.aspx

既に述べたように単純なケースでは、このDTOはビューへのバインドに使用できますが、より複雑なケースでは、ViewModelの作成とDTOからViewModelへのデータのアンロードが必要になるため、明らかに作業量が多くなります（MVVMパターンを適用する場合）。 。

したがって、すでに述べたように、DTO！= ViewModel

そして

DTOとViewModelの人生の目的は異なります

まず、大きな違いは、ViewModelがDTOがしてはならない動作またはメソッドを持つことができるということです!!!

2つ目は、ASP.NET MVCでViewModelとしてDTOを使用すると、アプリケーションがDTOと緊密に結合されます。これは、DTOを使用する目的とは正反対です。そうする場合、ドメインモデルまたはDTOを使用した場合の違いは何ですか？

また、ASP.NETのViewModelは検証にDataAnnotationsを使用できます。

同じDTOは異なるViewModelsマッピングを持つことができ、1つのViewModelは異なるDTOから構成できます（常にオブジェクトマッピングでは構成ではありません）。DTOを含むViewModelがあるとさらに悪いと思うので、同じ問題が発生します。

プレゼンテーションレイヤーから、DTOをコントラクトとして考えます。アプリケーションに対して他人と見なす必要があるオブジェクトを受け取り、それを制御することはできません（exサービス、dtoレイヤー、プレゼンテーションレイヤーがある場合でも）あなたのものです）。

最後に、このクリーンな分離を行うと、開発者は簡単に共同作業できます。ViewModel、ビュー、コントローラーを設計する人は、他の開発者が実装を完了したときにマッピングを行うため、サービスレイヤーやDTO実装について心配する必要はありません。テスト用のデータを含むプレゼンテーション層。

いくつかの単純なビューでは、モデルとしてDTOを使用しますが、ビューがより複雑になるにつれて、ViewModelを作成します。

私にとっては、それは迅速性（DTOを使用しているので、既に持っているので）と柔軟性（ViewModelを作成することで、関心事をより分離すること）のバランスです。

DTOをViewModelとして使用する場合は、何らかの理由でDTOを変更しているためにDTOへの依存度が高くなり、ViewModelに影響を与える可能性があります。

DTOを使用してビューモデルに変換することをお勧めします。

DTOが使えるModelクラスと同じで、単一のビューで複数のモデルデータ/プロパティを表示/使用する必要がある場合は、viewmodelを使用できます。例：最初にエンティティフレームワークデータベースを使用してモデルを作成します。したがって、すべてのモデルはデータベースに基づいて生成されます。次に、データアノテーションが必要です。これらのデータアノテーションには、フォルダー名DTOを作成できます。このDTOフォルダーでは、すべてのモデルを正確に保ち、​​データアノテーションをプロパティの上に追加して追加できます。次に、このDTOクラスを使用して、任意の操作（コントローラ、ビューを使用）を使用できます。複雑なビューが必要な場合、つまり1つのビューに複数のクラスデータが必要な場合は、viewmodelを使用できます。viewmodelの場合は、viewmodelというフォルダー名を作成し、カスタムクラスを作成して、必要なプロパティを保持できます。私は自分を片付けようとしました。どんな提案も高く評価されます。