中间层的验证

Question

我想对我的业务代码进行验证。我在想两种方法来做到这一点。

第一，以下列方式对我的类属性设置程序进行验证

class Student{
    public string Name{
        get { return _name; }
        set {
            if (value.IsNullOrEmpty) throw exception ...
        }
    } 
} 

现在，这种方法的问题是，每次分配名称时都会运行验证代码，我们可能不需要这样做，比如用DB提供的数据填充验证代码。

第二个，我更喜欢的是，将静态方法放在这些实体类上，比如

class Student {
    public **static** void ValidateName(**string name**) {
        if (string.IsNullorEmpty(name)) 
        {
            throw ...
        }
        ...
    } 

注意，我使用的是静态方法，而不是实例方法，如

class Student{
    public void Validate() {
        // validation logic on instance properties
        if (string.IsNullorEmpty(Name)) 
        {
            throw ...
        }

        ...
    } 

是因为我不总是得到一个学生obj传入，我确实得到了基元类型像字符串名传递到一个方法

public static FindStudentByName(string name)
{
   // here I want to first do validation
   Student.ValidateName(name);

   // query DB
   ...
}

如果我真的通过了学生讣告，那我当然可以做到。

public static AddStudent(Student s)
{
    // call the instance method
    s.Validate();
}

现在，我想让事情变得非常简单，所以我不希望采用以下任何一种方法

1. 对属性使用属性，如StringLength(25)。 第一，因为这需要反映并影响性能，所以有一些技巧可以降低性能，但我还是想让它越简单越好。 第二，我希望我的网站能够运行在中等信任。正如我所理解的那样，这需要充分的信任。
2. 使用任何一个验证块，比如在CodePlex上找到的Ms.EnterpriseLibrary等。

我想听听你对此的看法，

我使用的方法有哪些潜在的问题？

这种方法会比其他方法表现得更好、更易读、更容易维护吗？

您的中间层的验证工作如何？

感谢一群人！

雷。

Answer 1

我使用规则引擎在中间层执行域验证，非常类似于one 写在这里。朋友的项目使用类似于您在后一个示例中建议的方法，最终结果是不可维护的(脆弱、难以实现通用验证UI)。规则引擎方法是可维护的，因为它将所有验证和持久性规则本地化在一个组织良好的位置，并将每个规则作为一个成熟的类公开--但是在域类上公开验证，类似于您建议的那样。有些人喜欢动态编译，因此他们将它们存储在数据库中，以便进行高级别的部署后配置；在我的示例中，我喜欢检查它们的编译时间，以便在静态类上公开lambda的规则定义。

我知道这不符合你想做的事情，但问我怎么做，说其他方法还不够简单，就像说“你怎么能写可靠的代码，我想保持简单，这样单元测试就不可能了”。对我来说，将每条规则作为自己的类来处理是很好的，因为它更易于维护和文档化，尽管实现起来更加复杂。

Answer 2

选项二实际上并不强制验证，至少在没有手动调用验证的情况下是不会的。因此，对象的使用者可能会违反规则。

我个人将使用类似于第一个示例的内容，因为它确保所有数据都是有效的。这是对DB方面的额外检查，但据我所注意到，通常并不是什么大事。

Answer 3

您建议的方法似乎表明，不应该总是应用验证集。这没什么。我已经看到了很多规则和验证，我们希望“大多数时候”，但并不是总是如此。所以，问题变成了‘你想什么时候申请这些认证’？

比方说，你有一些你一直想申请的验证，有些你只想在.我不知道..您将保存到存储(数据库)。在这种情况下，应用始终的检查应该在属性中(请参阅下面的更多内容)，而那些仅在您要保存到存储时应用的检查应该在适当的时候调用的方法中(例如，在‘VerifyRulesForStorage’方法的中间)。

我认为，有一点值得考虑的是，当您在多个实体之间进行相同的验证时，可能会出现重复。无论是在属性中，还是在“VerifyRulesForStorage”方法中，您都可能在许多地方，在许多类中拥有相同的检查(例如: String.IsNullOrEmpty、CheckItsANumber或CheckItsOneOfTheAcceptedValues等)。当然，您可以通过继承(例如，所有实体继承自具有实现每种类型检查的方法的基本实体类)或组合(可能是一种更好的方法，以便您的实体的类树由其他更合适的注意事项驱动，例如:所有实体都有一个实现所有这些检查的Validator对象)来解决这个问题。无论哪种方式，您都可能希望远离静态方法，如果您是测试驱动的(在需要的时候，有一些方法)，它们往往会造成问题情况。

在我们的系统中，我们实际上有描述验证规则的元数据。类的属性名称用于检索正确的元数据，然后告诉系统要应用哪些规则。然后，我们有一个验证器对象，它通过工厂实例化适当类型的对象来实际执行验证(例如，我们有一个实现IsRequiredString规则的类，一个实现IsNumber规则，等等)。听起来很复杂，但在像我们这样的大系统里，这绝对值得。

最后，下架图书馆可能有一个很好的替代方案。在我们的情况下，他们并不是因为我们的特殊要求--但总的来说.使用别人开发(并将支持)你自己的轮子是有好处的(相信我，我喜欢在有可能的时候重建轮子。)我只是想说，有些情况下，每种方法都比另一种更好)。