数据层或域层的规则验证？

Posted 2023-02-24

技术标签:

【中文标题】数据层或域层的规则验证？【英文标题】：Rules Validation on Data or Domain layer? 【发布时间】：2010-11-26 12:53:46 【问题描述】：

我一直在阅读 Pro ASP.NET MVC Framework，Steven Sanderson，在第 11 章中讨论了数据验证。

在第 390 页，我们看到了将验证逻辑移动到您的模型层部分。在本节中，我们在第 392 页看到了一些代码，展示了如何实现验证。

代码实现了GetRuleViolations() 方法，Save() 方法使用它在出现问题时抛出RuleException。

然而，在我看来，领域层和数据访问层之间没有区别，代码如下：

public void Save() 
    var errors = GetRuleViolations();
    if (errors.Count > 0)
        throw new RuleException(errors);

    // Todo: Now actually save to the database or whatever

private NameValueCollection GetRuleViolations() 
    // validations...

在我正在工作的一个项目中，我有一个 Domain 层，尽可能地忽略持久性，还有一个 Data Access 层，通过 NHibernate 实现数据访问，并实现在域层中定义接口的存储库。

如果我按照作者在此处建议的方式实施验证规则，在“Save()”方法上，它们将继续我的数据访问层，尽管至少我认为它们应该驻留在域模型上！

所以，我的问题是：在创建分层应用程序时，域层实现域实体并将接口暴露给存储库（ persistence ignorant），数据访问层从域层实现存储库并实现所有数据访问代码，验证规则应该驻留在哪里 ?

我的主要（或至少第一个）界面将是一个 ASP.NET MVC 应用程序，如果这可能会改变的话。

谢谢。

【问题讨论】：

实际上我有两个不同的想法在我的脑海中争斗：（1）如果我决定写一个新的 DAL，我不想重写所有相同的规则（DRY）——以避免错过一条规则，或产生错误，或必须多次重新实施所有新规则； (2) 很难在域上实现“上下文验证”（因为我每次处理它时都必须在域上注入有关上下文的详细信息）...... 【参考方案1】：

在 MVC 架构中，M（模型）包括both领域层和数据访问层。所以桑德森的例子没有错。

也就是说，当您使用这两个层（而不是只有一个）实现域模型时，验证逻辑应该转到域层以增加域对象的凝聚力并避免验证逻辑在许多地方重复（例如在每个具体的存储库中）。

【讨论】：

我同意，但是“上下文验证”呢？例如，域对象是有效的，它们已经准备好被持久化，但是有一条规则说如果通过用户的窗口可以看到一辆红色的汽车，那么他就不能保存该对象。此规则携带有关保存操作的地点/时间的上下文信息。该信息将来自一项服务，该服务提供所有附近停放的汽车的列表（即，不在您的项目中的东西）。该验证规则将在哪里执行，同时遵循 DRY 原则？在执行保存的服务方法中。我通常在我的 ASP.NET MVC 应用程序中有这些层：控制器 --> 服务 --> 存储库。跨这些层使用域对象。服务（不是控制器）应该在域对象中触发验证。然后由服务执行上下文验证，例如保存域对象。所有这些东西（例如服务、存储库和域对象，即实体）都是域驱动设计的概念。为什么干燥？例如。您可以在 WebForms 应用程序中重用所有这些（服务、存储库和实体）而无需更改。 Buu Nguyen：Martin Fowler 指出“你在服务中发现的行为越多，你就越有可能剥夺自己从领域模型中获得的好处。如果你所有的逻辑都在服务中，你把自己骗瞎了。” (martinfowler.com/bliki/AnemicDomainModel.html) 说，你的模型贫血。【参考方案2】：

它们绝对属于您的域层（您可以在其中实现 IDataErrorInfo，但我认为这只对 Windows 窗体或 WPF 应用程序有用）。

看起来这种验证理念与Paul Stovell 公开的理念非常相似（请查看this article of his）。它非常强大，我经常使用它。基本上：