11

次のような POCO があるとします。

public class Name
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

FirstName と LastName を null にすることはできません。次のようなメソッドを追加する必要があります。

public List<Error> Validate()
{
    var errors = new List<Error>();

    if (String.IsNullOrEmpty(FirstName))
        errors.Add(new Error("FirstName", "You must fill out first name."));
    if (String.IsNullOrEmpty(LastName))
        errors.Add(new Error("LastName", "You must fill out last name."));
}

whereErrorは を含む構造体ですNameValueDictionary。これは物事を行う良い方法ですか？誰かがこの POCO をValidate()最初に実行せずに保存しようとすると、リポジトリに問題が発生する可能性があります。

4

3 に答える 3

4

私はしません。私の POCO は、コンテキストに基づいて異なる検証を行う傾向があります。「私の人物オブジェクトは、このアプリケーションでは住所を持っている必要がありますが、この他のアプリケーションでは電話番号だけを持っている必要があります」...これは、目を光らせて柔軟に対応したい類のものです。

私は通常、同じドメインを再利用しますが、コンテキストに基づいて異なる動作と検証を割り当てるため、貧血ドメイン モデルの支持者です (同じアプリケーションの異なる領域である可能性もあります)。

新しい機能を実装するとき、私は通常自分のクラスを見て、この質問を自問します: これはこのクラスの責任のように見えますか? それとも、別の責任のセットを持つクラスにより適しているでしょうか? このチェックを「Feature Envy」と呼んでおり、クラスが何であるか、関心がないかを効果的に分離するのに役立ちます。

于 2009-09-25T22:19:04.797 に答える
2

xValのようなアスペクト指向の検証フレームワークの使用を検討してください。

検証ルールをコードに直接組み込む代わりに、それらをプロパティの属性として追加し、依存関係をオフロードできます。クラスは次のようになります。

public class Name
{
    [Required]
    public string FirstName { get; set; }
    [Required]
    public string LastName { get; set; }
}

あなたの質問にもっと直接的に答えるために、検証ルールを POCO に追加することは、機能する簡単な方法ですが、維持するのが面倒になる可能性があり、すべてのオブジェクトに Validate インターフェースを適用する必要があります。自分の頭痛。アスペクト指向のソリューションは、これらの問題や他の多くの問題に対処する非常に洗練されたソリューションです。

于 2009-09-25T22:03:55.843 に答える
0

モデルに検証を入れても問題はありません。これは、モデルが有効かどうかを尋ねることができることを期待する Microsoft のすべての UI テクノロジでうまく機能し、ある DTO を別の DTO にマッピングし続けず、ビューまたは編集モデルで検証を繰り返すことになります (またはさらに悪いことに、そこに置くだけです）。

サンプルのルールは単純ですが、多くの場合、より複雑なルールを記述する必要があります。おそらく、Csla.Net フレームワークを確認する必要があります。

于 2011-03-25T22:59:52.417 に答える