2

通常、ビューにエンティティを渡してはいけないと言っている人を見かけます。エンティティを使用すると結合が増加するため、代わりに DTO/VO/ViewModel/AnyOtherThingYouWant を使用する必要があると彼らは言います。追加のロジックが必要な場合 (または、すべてのプロパティが必要ない場合) を無視すると、これを行う利点がわかりません。たとえば、次のクラスを考えてみます。

public class Contact {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

次のように、別のクラスを作成するコードがたくさんあります。

public class ContactDTO {
    public int Id { get; set; }
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
}

ビューで使用してから、次のようにします。

someMapper.Map(contactDto).To<Contact>();

ビューはエンティティのクラスに結合されたクラスに結合されるため、単純に Contact クラスを使用するよりもこれがどれほど優れているかわかりません。したがって、一方のすべての変更を他方に複製する必要があります。私の見解では、「中間」オブジェクトは複雑さを追加するためだけに存在し、実際の価値はありません。「フリーサイズ」の解決策がないことは知っていますが (中間オブジェクトを使用することが理にかなっている場合もあります)、このようなコードを追加する必要は本当にあるのでしょうか? 本当のメリットとは？

4

2 に答える 2

4

このように考えてください: ビューはドメインの射影です。これは、ビジネス モデルを具体的に表したものです。したがって、この投影を表すビュー モデルを使用する必要があります。これはドメイン モデルのサブセットである可能性がありますが、ビューで必要な場合は複数のドメイン モデルの集約である可能性もあります。あなたが提供した例は、この特定のビューの要件のために、ドメイン モデルとビュー モデルの間に 1:1 のマッピングがある特定のケースにすぎません。しかし、それは 1 つの特定のビューにすぎません。あなたのアプリケーションには、ドメイン エンティティの多くのビューとさまざまな表現があると思います。

ドメイン モデルを不適切にするビュー固有の要素が多数あり、ビュー モデルが必要になります。たとえば、検証。特定のドメイン モデル プロパティは、あるビューでは必須であり、別のビューでは必須ではない場合があります (Create/Update ビューの Id プロパティを考えてみてください)。ビュー モデルを使用せずに、コントローラーの作成アクションでドメイン モデルを直接取得する場合、ドメイン モデルの Id プロパティが Required 属性で修飾されていると問題が発生します。

他にもたくさんの例があります。ASP.NET MVC アプリケーションを開発する際に 1 つのアドバイスがあるとすれば、次のようになります。常にビューに対して特定のビュー モデルを定義し、ビューとの間でドメイン モデルをやり取りしないでください。ドメイン モデルとビュー モデル間の 1:1 マッピング。

于 2011-10-23T20:06:58.727 に答える
3

引用されたアプローチは一種の純粋主義です。ドメインオブジェクトを変換（縮小、マージなど）する必要がなく、ビューでそのまま使用できる場合は、それらを使用します。必要に応じて、後でリファクタリングを介してDTOを導入できます。

したがって、Darin Dimitrovが言ったことを考慮に入れる必要がありますが、作業を容易にするためにDTOなどがここにあることを覚えておいてください。私が取り組んだ1つのプロジェクトを思い出します-DTOの90％以上がドメインオブジェクトの1対1のコピーでした-これはまったく役に立たず、メンテナンスコストを増やすだけです。

于 2011-10-24T10:15:12.713 に答える