3

私は最近、DTOについて多くのことを読んでいますが、これまで使用したことはありません。私が読んだある記事では、DTOがドメインモデルオブジェクトを複製するだけでなく、実行されているサービス操作に合わせて各DTOを調整する方法について説明しました。

これにより、DTOを使用することにした場合の検証について考え、次のことが許容できるかどうか疑問に思いました。

public class Person {
    public Guid Id {get; set;}
    public string Name {get; set;}
    public Address Address {get; set;}
}

public class Address {
    public Guid Id {get; set;}
    public string AddressLine1 {get;set;}
    ...
}

publuc class CreatePersonDTO {
    private string _name;
    private string _addressLine1;

    public string Name {
        get {
             if (_name == null)
                 throw new Exception("Missing");

             return _name;
        }
        set { _name = value; }
    }

    public string AddressLine1 {
        get { return _addressLine1; }
        set { _addressLine1 = value; }
    }
}

したがって、JsonまたはXmlのいずれかでデータを渡し、オブジェクトCreatePersonDTOにシリアル化されます。これらの値をマッピングして、PersonおよびAddressオブジェクトを作成するときに、Persons Nameがない場合は、検証例外がスローされます。

DTO自体はサービス操作に固有であるため、ここでこの検証を行うことは問題ありませんか、それともビジネスロジックが存在する場所に関するある種のルールに違反していますか？

4

4 に答える 4

4

DTOには検証がないはずです。それらは厳密にデータを転送するためのものです。検証を超えて、それらは実際にはまったく動作しないはずです。

名前が必要な場合、それはドメインまたは特定のサービス操作のいずれかの側面です。検証は、対応する場所にカプセル化する必要があります（ただし、より良いエクスペリエンスのためにUIでルールを適用することもできます）。

于 2012-09-04T15:49:17.670 に答える
2

各DTOは、実行されているサービス操作に合わせて調整する必要があると解釈します。つまり、かさばるドメインオブジェクトがある場合、DTOは特定のサービス操作に関連するサブセットを表すことができます。つまり、ドメインオブジェクトのいくつかのプロパティにのみ関心がある可能性があります。

于 2012-09-04T15:48:54.813 に答える
1

場合によります。ただし、通常、検証ログインをDTOに配置するのは適切な場所ではありません。再利用性に問題があります。たとえば、personを更新する必要がある場合は、UpdatePersonDTOを作成し、そこにすべて同じロジックを配置する必要があります。
別のオプションとして、検証ロジックをPerson自体に配置して、無効なPersonを作成できず、再利用できるようにすることができます。または、エンティティ検証ロジックをある種のサービスレイヤーに配置することもできます。

于 2012-09-04T15:48:10.463 に答える
1

検証ロジックをDTOに配置しないでください。これは、主にドメインレイヤーによって処理され、場合によってはUIレイヤーで複製される必要があります。DTOは、データを転送するためのダムオブジェクトである必要があります。

ここでの責任の分離を超えて、ロジックを実際にシリアル化することはできません。有線で転送されるのは値自体だけです。このオブジェクトを.NET以外のコンシューマー（たとえば、WCF経由）に渡す場合、データを逆シリアル化するのと同じルールがオブジェクトに組み込まれているとは限りません。

于 2012-09-04T15:50:50.323 に答える