DTO = ViewModel？
私はNHibernateを使用してドメインオブジェクトを永続化します。物事を簡単にするために、ASP.NET MVCプロジェクトをプレゼンテーション層とサービス層の両方として使用しています。
コントローラークラスからドメインオブジェクトをXMLで返したい。ここでStack Overflowに関するいくつかの投稿を読んだ後、DTOを収集する方法があります。しかし、私はViewModelについての記事にも出くわしました。
私の質問：データ転送オブジェクトとViewModelは同じものですか？または、ViewModelはDTOの一種のサブパターンですか？
DTOの標準的な定義は、動作のないオブジェクトのデータ形状です。
ViewModelsは、ビューのモデルです。 ViewModelは通常、1つ以上のオブジェクト（またはDTO）からの完全または部分的なデータと、ビューの動作に固有の追加メンバー（ビューによって実行できるメソッド、ビュー要素の切り替え方法を示すプロパティなど）です。ビューモデルは、ビューのすべてのデータと動作として見ることができます。 ViewModelは、1対1をビジネスオブジェクトまたはDTOにマップする場合としない場合があります。
ところで、NHibernate projections は、特定のビューモデルが永続オブジェクトからのデータのサブセットを必要とする場合に便利です。
ASP.NET MVCのViewModelはDTOと同じですが、MVVMのViewModelには動作がありますがDTOにはないため、MVVMパターンのViewModelはDTOとは異なります。
DTO！= ViewModel
[〜＃〜] mvvm [〜＃〜] パターンでは、ViewModelを使用して、モデルをビューから分離します。モデルを表すには、単純な [〜＃〜] dto [〜＃〜] クラスを使用できます。このクラスは、たとえば、 NHibernate。しかし、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がしてはならない動作やメソッドを含めることができるということです!!!
次に、DTOをASP.NET MVCのViewModelとして使用すると、アプリケーションがDTOに密結合されます。これは、DTOを使用する正反対の目的です。その場合、ドメインモデルまたはDTOを使用した場合の違い、アンチパターンを取得するためのより複雑なものは何ですか？
また、ASP.NETのViewModelは検証にDataAnnotationsを使用できます。
同じDTOは異なるViewModelsマッピングを持つことができ、1つのViewModelは異なるDTOから構成できます（常に構成ではなくオブジェクトマッピングを使用）。 DTOを含むViewModelがあるとさらに悪いと思うので、同じ問題が発生します。
プレゼンテーションレイヤーから、DTOをコントラクトとして考えます。アプリケーションに対して見知らぬ人と見なさなければならないオブジェクトを受け取り、それを制御することはできません（元のサービス、dto、およびプレゼンテーションレイヤーがあっても）あなたのものです）。
最後に、このクリーンな分離を行うと、開発者は簡単に共同作業できます。 ViewModels、Views、およびControllersを設計する人は、他の開発者が実装を完了したときにマッピングを作成するため、サービス層またはDTO実装について心配する必要はありません。テスト用のデータを含むプレゼンテーション層。
いくつかの単純なビューでは、モデルとしてDTOを使用しますが、ビューがより複雑になると、ViewModelを作成します。
私にとっては、迅速性（すでにDTOを使用しているため）の柔軟性と、柔軟性（ViewModelを作成することで懸念事項がより分離されます）のバランスです。
DTOをViewModelとして使用する場合、何らかの理由でDTOを変更しているためにDTOに高い依存度を設定している場合、ViewModelに影響を与える可能性があります。
DTOをより適切に使用し、ビューモデルに変換します。