规范模式与（流利）验证答案

【问题标题】：Specification Pattern vs (Fluent) Validation规范模式与（流利）验证
【发布时间】：2021-01-05 19:33:07
【问题描述】：

Specification Pattern 和 (Fluent) Validation 有什么不同？它们相似吗？

// Specification
public class PremiumSpecification<T> : CompositeSpecification<T>
{
    private int cost;
    public PremiumSpecification(int cost) {
        this.cost = cost;
    }
 
    public override bool IsSatisfiedBy(T o) {
        return (o as Mobile).Cost >= this.cost; // HERE
    }
}

// Fluent Validation
public class CustomerValidator : AbstractValidator<Customer> {
  public CustomerValidator() {
    RuleFor(customer => customer.Cost).GreaterThanOrEqualTo(0);
  }
}

【问题讨论】：

标签： c# design-patterns domain-driven-design

【解决方案1】：

您的两个示例都在进行验证，但在风格上不同。

第一个使用继承和组合来指定如何执行验证，覆盖包含验证逻辑的方法。这是大多数人认为的 the Specification Pattern 的实例。

第二个使用更扁平的结构（尽管不是必须的）和RuleFor() 规范，它将验证逻辑作为针对某个主题执行的表达式。这不是规范模式的一个实例，但您可以说它是 a 规范模式，因为 RuleFor() 是关于要做什么的声明性声明（或规范）做。

虽然后者的名称中有“Fluent”，但原因不同：它依赖于fluent interface 编程风格。您可以在您的示例中看到这一点，因为它使用 method chaining 和 RuleFor() 返回一个对象，其中立即调用 GreaterThanOrEqualTo() 而不将 RuleFor() 的结果分配给临时变量。

编辑：在实践中，我经常看到 DDD 中使用的规范模式，因为每个规范都可以通过规范的 name 非常清楚地传达重要的域验证或约束。在实践中，我看到第二种验证模式更常用于用户输入，然后再对域进行水合。

这完全是轶事，绝不是绝对的规则。

【讨论】：

其实除了风格，我们用哪一种都没关系？（尤其是在 DDD 中）
你必须做出这样的判断，但在高层次上，我会说不，这并不重要。使用适合您项目的内容。也就是说，the 规范模式出现了，从表面上看，更清楚地表达了您的领域概念。希望我已经回答了你的问题。