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