asp.net-mvc - 使用扩展方法验证域模型

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 中的“delinquent”而不是通用的“valid”。请参阅类似的答案: 1 、 2 、 3 。

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