Question

我经常看到人们通过创建接受委托来执行验证的规则对象来验证域对象。比如这个例子“：http://www.codeproject.com/KB/cs/DelegateBusinessObjects.aspx

我不明白的是，如果只是制作一种方法，这有什么用呢？

例如，在该特定文章中，有一种方法可以创建委托以检查字符串是否为空。

但这与仅仅有这样的东西不一样：

Bool validate()
{
    Result = string.IsNullOrEmpty(name);
}

当这些规则对上下文敏感且可能无法共享时，为什么要经历使对象保持规则并在委托中定义规则的麻烦。用方法可以达到完全相同的效果。

Answer 1

有几个原因：

SRP - 单一责任原则。对象不应对其自身的验证负责，它有自己的责任和存在的理由。

此外，当涉及复杂的业务规则时，明确说明它们会使验证代码更易于编写和理解。

业务规则也往往会发生很大变化，比其他域对象更多，因此将它们分开有助于隔离更改。

您发布的示例太简单，无法从完全成熟的验证对象中受益，但它非常方便，一个系统变大，验证规则变得复杂。

Answer 2

这里显而易见的例子是一个webapp：你填写表格然后点击“提交”。你的一些数据是错误的。会发生什么？

某事抛出异常。某些东西（可能更高）捕获异常并打印它（可能你只捕获UserInputInvalidExceptions，假设应该只记录其他异常）。你看到第一件事是错的。
您编写了validate（）函数。它说“不”。你向用户展示了什么？
编写一个validate（）函数，该函数返回（或抛出异常，或附加到）消息列表。你显示消息......但按字段分组不是很好吗？或者将它显示在错误的字段旁边？你使用元组列表还是列表元组？您希望规则占用多少行？

将规则封装到对象中可以让您轻松地遍历规则并返回已损坏的规则。您不必为每个规则编写样板附加消息到列表代码。你可以在破坏它们的领域旁边修改破坏的规则。