Question

假设我有一个像这样的POCO：

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

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

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

我不会。我的POCO倾向于根据其上下文进行不同的验证。 “我的Person对象必须在这个应用程序中有一个地址，但是他们只需要在另一个应用程序中有一个电话号码”......这是你想要关注并且灵活的东西。

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

在实现新功能时，我通常会查看我的课程并问自己这个问题：这看起来像是这门课的责任，还是更适合具有不同职责的班级？我们将此检查称为“功能羡慕”，它有效地帮助分离出类和不关心的内容。

Answer 2

考虑使用面向方面的验证框架，如xVal。

您不必将验证规则直接合并到代码中，而是可以将它们添加为属性的属性，并卸载依赖项。你的课程看起来像这样：

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

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

Answer 3

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

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

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

3 个答案: