使用扩展方法验证域模型

Question

我一直在研究使用service layer 来验证我的域模型，然后再将它们持久化到数据库中。

我发现following example 使用扩展方法来验证我的模型，但想知道这样做是否有任何特定的缺点？我没有看到太多提及验证（除了数据注释）。

我正在考虑实现以下内容：

public class FooService : IFooService {

    public bool Add(Foo foo) {

        if (!foo.IsValid()) {
            return false
        }

        try ... catch
    }
}

---

public static class validationExtensions {

    public static bool IsValid(this Foo foo) {

        // Call my validation implementation here
    }
}

我很紧张，因为我没有看到太多推荐/实施的。想法？

Answer 1

域对象应该是自我验证的，这是简单的 OOP。首先不应该允许他们进入无效状态。正确设计的域对象在不依赖外部代码的情况下强制执行所有内部不变量。否则封装会被破坏，你的对象实际上只是一个带有 getter 和 setter 的哑数据容器。

“验证”这个词也可能是一种非常危险的过度概括，它倾向于将焦点从域和对象转移到为选择的 UI 框架量身定制的愚蠢数据容器上。这就是为什么DDD book 根本没有提到“验证”问题的原因。我发现考虑不变比考虑验证更有用。不变量可以像“社会安全号码不能有字母”一样简单，在这种情况下应该使用Value object。或者更复杂的，比如“如果在 2 周内没有付款，则认为订单拖欠”，可以封装在 order.IsDelinquent() 或类似方法中。请注意，在第一种情况下，我们通过实现SocialSecurityNumber 类来消除对象无效的可能性。在第二种情况下，我们使用来自ubiquitous language 的“拖欠”一词，而不是通用的“有效”。请查看类似答案：1、2、3。

作为旁注，您可能应该对来自 ASP.NET 人群的所有“DDD”建议持保留态度。 ASP.NET MVC 是一个很棒的框架，但学习材料将域模型与视图模型混淆了。大多数示例都认为“域”对象与具有 getter 和 setter 的数据容器相同，没有任何封装。 DDD 与技术无关，因此您始终可以通过问自己“这在控制台应用程序中有意义吗？”来进行现实检查。或者“这在非 UI 项目中有意义吗？”。