データ検証の設計パターン

この問題に最適な設計パターンは次のとおりです。

オブジェクトAがあります。オブジェクトAは、ユーザーの要求に応じてデータベースに登録または削除できます。

データの検証は、オブジェクトの登録または削除の前に実行されます。オブジェクトを登録する前にチェックするルールのセットと、削除する別のルールのセットがあります。これらのルールの一部は、両方の操作に共通です。

これまでのところ、Chain of Responsibilityのデザインパターンが最も適していると思いますが、実装に問題があります。

通常、各ユースケースを検証するために個別のバリデータークラスを使用します。たとえば、データベースに製品を追加する前に、AddProductValidatorを使用してビジネスルールを検証します。製品を削除する前に、DeleteProductValidatorを使用して検証します。

バリデータクラスを構造化するには、次のアプローチに従います。http：//lostechies.com/jimmybogard/2007/10/24/entity-validation-with-visitors-and-extension-methods/

.NETを使用している場合、Fluent Validation（https://github.com/JeremySkinner/FluentValidation）を検討することをお勧めします。かなりクールで、上記の記事に非常に近いと思います

説明したように、おそらくオプションタイプを実装します。そうすれば、「なし」または検証済みの値（おそらく遅延）を返すことができますが、それは実装の詳細であり、Decoratorを使用するという考えにうまくつながります。

もちろん、インターフェイスがくなる場合は、ファサードを使用します。