如何将数据验证与简单域对象 (POCO) 分开？

Question

这个问题与语言无关，但我是 C# 人员，所以我使用术语 POCO 来表示仅执行数据存储的对象，通常使用 getter 和 setter 字段。

我刚刚将我的域模型重新设计为超级 POCO，并且对如何确保属性值在域中有意义存在一些担忧。

例如，服务的结束日期不应超过该服务所依据的合同的结束日期。 然而，将检查放入 Service.EndDate setter 中似乎违反了 SOLID，更不用说随着需要完成的验证数量的增加，我的 POCO 类将变得混乱。

我有一些解决方案（将在答案中发布），但它们有其缺点，我想知道解决这个困境的一些最喜欢的方法是什么？

Answer 1

我认为您一开始就有一个错误的假设，即您应该拥有除了存储数据之外不执行任何操作的对象，并且除了访问器之外没有任何方法。 拥有对象的全部意义在于封装数据和行为。 如果你有一个基本上只是一个结构的东西，那么你要封装什么行为？

Answer 2

我总是听到人们争论“Validate”或“IsValid”方法。

就我个人而言，我认为这可能可行，但对于大多数 DDD 项目，您通常最终会这样
根据对象的具体状态，可以进行多次验证。

所以我更喜欢“IsValidForNewContract”、“IsValidForTermination”或类似的，因为我相信大多数项目最终每个类都会有多个这样的验证器/状态。 这也意味着我没有接口，但我可以编写聚合验证器，这些验证器读取很好地反映了我所断言的业务条件。

我确实相信，在这种情况下，通用解决方案经常将注意力从重要的事情（代码正在做什么）上转移开来，以获取技术优雅（接口、委托或其他）的微小收益。 只要投票给我就可以了;)

Answer 3

我的一位同事想出了一个想法，效果非常好。 我们从来没有给它想出一个好听的名字，但我们称之为检查员/法官。

检查员会查看一个对象并告诉您它违反的所有规则。 法官将决定如何处理。 这种分离让我们可以做一些事情。 它让我们将所有规则放在一个地方（检查员），但我们可以有多个法官并根据上下文选择法官。

使用多个法官的一个例子围绕着“客户必须有地址”这一规则。 这是一个标准的三层应用程序。 在 UI 层中，Judge 将生成 UI 可以用来指示必须填写的字段的内容。UI Judge 不会抛出异常。 在服务层还有一个法官。 如果在保存期间发现客户没有地址，则会引发异常。 到那时你真的必须阻止事情继续进行。

随着对象状态的变化，我们也有更严格的判断。 这是一份保险申请，在报价过程中，允许以不完整的状态保存保单。 但是，一旦该政策准备好生效，就必须设置很多事情。 所以服务端的Quoting Judge并没有Activation Judge那么严格。 然而，检查器中使用的规则仍然相同，因此即使您决定不采取任何措施，您仍然可以看出哪些内容不完整。

Answer 4

一种解决方案是让每个对象的 DataAccessObject 获取验证器列表。 当调用 Save 时，它​​会对每个验证器执行检查：

public class ServiceEndDateValidator : IValidator<Service> {
  public void Check(Service s) {
    if(s.EndDate > s.Contract.EndDate)
      throw new InvalidOperationException();
  }
}

public class ServiceDao : IDao<Service> {
  IValidator<Service> _validators;
  public ServiceDao(IEnumerable<IValidator<Service>> validators) {_validators = validators;}
  public void Save(Service s) {
    foreach(var v in _validators)
      v.Check(service);
    // Go on to save
  }
}

好处是非常清晰的 SoC，缺点是我们在调用 Save() 之前不会得到检查。

Answer 5

过去，我通常将验证委托给服务自己，例如 ValidationService。 这原则上仍然遵循 DDD 的哲学。

在内部，这将包含一组验证器和一组非常简单的公共方法，例如 Validate() ，它可以返回错误对象的集合。

非常简单，C# 验证器中的类似内容

public class ValidationService<T>
{
  private IList<IValidator> _validators;

  public IList<Error> Validate(T objectToValidate)
  {
    foreach(IValidator validator in _validators)
    {
      yield return validator.Validate(objectToValidate);
    }
  }
}

可以添加到默认构造函数中，也可以通过其他类（例如 ValidationServiceFactory）注入。

Answer 6

实际上，我认为这可能是逻辑的最佳位置，但这只是我的想法。 您可以使用某种 IsValid 方法来检查所有条件并返回 true/false，可能是某种 ErrorMessages 集合，但这是一个不确定的主题，因为错误消息实际上并不是域模型的一部分。 我有点偏见，因为我已经对 RoR 做了一些工作，而这本质上就是它的模型所做的。

Answer 7

另一种可能性是让我的每个类实现

public interface Validatable<T> {
  public event Action<T> RequiresValidation;
}

并让每个类的每个设置器在设置之前引发事件（也许我可以通过属性来实现这一点）。

优点是实时验证检查。 但代码比较混乱，并且不清楚谁应该进行附加操作。

Answer 8

这是另一种可能性。 验证是通过域对象上的代理或装饰器完成的：

public class ServiceValidationProxy : Service {
  public override DateTime EndDate {
    get {return EndDate;}
    set {
      if(value > Contract.EndDate)
        throw new InvalidOperationexception();
      base.EndDate = value;
    }
  }
}

优点：即时验证。 可以通过 IoC 轻松配置。

缺点：如果是代理，则验证的属性必须是虚拟的，如果是装饰器，则所有域模型都必须基于接口。 验证类最终会变得有点重量级 - 代理必须继承该类，而装饰器必须实现所有方法。 命名和组织可能会令人困惑。