我应该将验证逻辑放在 POCO 中吗？

Question

假设我有一个这样的 POCO：

public class Name
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
}

FirstName 和 LastName 不能为空。我应该添加这样的方法吗：

public List<Error> Validate()
{
    var errors = new List<Error>();

    if (String.IsNullOrEmpty(FirstName))
        errors.Add(new Error("FirstName", "You must fill out first name."));
    if (String.IsNullOrEmpty(LastName))
        errors.Add(new Error("LastName", "You must fill out last name."));
}

其中Error 是一个包含NameValueDictionary 的结构。这是做事的好方法吗？我可能会看到存储库存在问题，有人尝试保存此 POCO，而不首先通过 Validate() 运行它。

Answer 1

我发现在模型中进行验证没有错。它适用于所有 Microsoft 的 UI 技术，这些技术期望可以询问模型是否有效，并且您不会一直将一个 DTO 映射到另一个 DTO，只会在视图或编辑模型中重复您的验证（或更糟糕的是，只把它放在那里）。

示例中的规则很简单，但您通常需要编写更复杂的规则。您可能应该查看 Csla.Net 框架。

Answer 2

我不会。我的 POCO 往往会根据他们的上下文进行不同的验证。 “我的 Person 对象在这个应用程序中必须有一个地址，但在这个其他应用程序中它们只需要一个电话号码”......这是您要密切关注并灵活处理的事情。

我是贫血域模型的拥护者，因为我通常会重复使用同一个域，但会根据上下文分配不同的行为和验证（甚至可能是同一应用程序的不同区域）。

在实现新功能时，我通常会查看我的类并问自己这个问题：这看起来像是这个类的职责，还是更适合具有不同职责的类？我们将此检查称为“Feature Envy”，它有效地有助于区分类是什么和不关心什么。

Answer 3

考虑使用像xVal 这样的面向方面的验证框架。

不必将验证规则直接合并到代码中，您可以将它们添加为属性的属性，并卸载依赖项。你的班级应该是这样的：

public class Name
{
    [Required]
    public string FirstName { get; set; }
    [Required]
    public string LastName { get; set; }
}

为了更直接地回答您的问题，将验证规则添加到您的 POCO 是一种可行的简单方法，但维护起来可能很繁琐，您需要在所有对象中强制执行 Validate 接口，这是它自己的头痛。面向方面的解决方案是一种非常优雅的解决方案，可以解决这些问题以及许多其他问题。