検証デザインパターン

Question

私は、次の要件を満たす私たちの部門のデータ検証ユーティリティを作成しています。 - 新しいビジネスエンティティを動的に追加する - エンティティに新しい検証を動的に追加します。 - ビジネスエンティティとそのバリデーションのリストを表示するためのUI - ユーザーは、すべてのビジネスエンティティまたは有効なビジネスエンティティのバリデーションに対して検証を開始するオプションがあります。 - 検証に失敗した場合、UIに検証エラーメッセージが表示されます。 - いずれかの検証が失敗しても、次の検証に進む必要があります。したがって、設定された検証はすべて検証されます。

インターネットを検索した後、私のビジネス要件を満たしている2つのデザインパターンを見つけました。idデコレータパターンと別のものがコマンドチェーン（別名Chain of Responsibilty）です。今私の質問は良いですか？誰もが良いアイデアを持っていますか？

おかげ

Answer 1

私が何をしたいことはSpecification Patternだと思います。このパターンのいいところは、各ルールが孤立して簡単にテスト可能であることであり、あなたはこれを課すいくつかのフレームワークとは対照的に、（検証ルールを適用する際に選択してもらう

public void StartDateNotInPastSpecification : ISpecification<ISomeBusinessObject> 
{ 
    public bool IsSatisfiedBy(ISomeBusinessObject myBusinessObject) 
    { 
    return myBusinessObject.StartDate >= DateTime.Now; 
    } 
} 

：だから、このような何かをするだろうあなたの決定）。

Answer 2

私は仕様パターンも使用しています。これは基本的な実装です。この実装では

public class Specification<T, E> : ISpecification<T, E> 
{ 
    private Predicate<T> predicate; 

    public Specification(Predicate<T> predicate) 
    { 
     this.predicate = predicate; 
    } 

    public bool IsSatisfiedBy(T candidate) 
    { 
     return this.predicate.Invoke(candidate); 
    } 
} 

、私はコンストラクタで述語を渡し、次のように：代わりに、いくつかのクラス（自分のドメイン内の各条件につき1）の

var specification = new Specification<SomeDomainClass>(x => x.SomeDomainBoolMethod()); 

、私は中にいくつかのブールメソッドを持っています私のビジネスオブジェクト。