11

假设我有一个像这样的 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."));
}

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

4

3 回答 3

4

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

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

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

于 2009-09-25T22:19:04.797 回答
2

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

不必将验证规则直接合并到代码中，您可以将它们添加为属性的属性，并卸载依赖项。您的课程将如下所示：

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

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

于 2009-09-25T22:03:55.843 回答
0

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

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

于 2011-03-25T22:59:52.417 回答