Getter/Setter 或其他地方的数据验证？

Question

我想知道在getter和setter或代码中的其他地方进行验证是否是个好主意。

当涉及到优化和加速代码时，这可能会让您感到惊讶，我认为您不应该在 getter 和 setter 中进行验证，而应该在更新文件或数据库的代码中进行验证。 我错了吗？

Answer 1

好吧，类通常包含具有公共 getter/setter 的私有成员的原因之一正是因为它们可以验证数据。

如果您有一个介于 1 和 100 之间的数字，我肯定会在 setter 中放入一些东西来验证它，然后可能会抛出一个被代码捕获的异常。 原因很简单：如果没有在setter里面做，每次设置都要记住1到100的限制，这样会导致代码重复或者忘记了就会导致无效状态。

至于性能，我和 Knuth 在一起：

“我们应该忘记小效率，比如大约 97% 的时间：过早的优化是万恶之源。”

Answer 2

@Terrapin，回复：

如果你所拥有的只是一堆 [simple public set/get] 属性……它们也可能是字段

与字段相比，属性还有其他优势。 它们是一个更明确的契约，它们被序列化，它们可以在以后调试，它们是通过继承进行扩展的好地方。 笨拙的语法是一种偶然的复杂性——例如.net 3.5 克服了这一点。

一种常见（且有缺陷）的做法是从公共字段开始，然后在“根据需要”的基础上将它们转换为属性。 这违反了您与使用您的课程的任何人的合同，因此最好从属性开始。

Answer 3

从拥有最可维护的代码的角度来看，我认为您应该在属性的 setter 中尽可能多地进行验证。 这样您就不会缓存或以其他方式处理无效数据。

毕竟，这就是属性的意义所在。 如果您拥有的只是一堆属性，例如...

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

...它们也可能是字段

Answer 4

这取决于。

通常，代码应该很快失败。 如果该值可以由代码中的多个点设置，并且您仅在检索该值后进行验证，则错误似乎在执行更新的代码中。 如果 setter 验证输入，您就知道哪些代码试图设置无效值。

Answer 5

我尽量不让我的对象进入无效状态，所以 setter 肯定会有验证以及任何改变状态的方法。 这样，我永远不必担心我正在处理的对象无效。 如果您将方法作为验证边界，那么您就不必担心到处都是验证框架和 IsValid() 方法调用。

Answer 6

验证应与验证方法中的 getter 或 setter 分开捕获。 这样，如果验证需要跨多个组件重用，它就可用。

当 setter 被调用时，应该使用这样的验证服务来清理对象的输入。 这样您就知道存储在对象中的所有信息在任何时候都是有效的。

您不需要对 getter 进行任何类型的验证，因为有关对象的信息已经被认为是有效的。

在数据库更新之前不要保存您的验证！！ 最好快速失败。

Answer 7

你可能想看看 Eric Evans 的领域驱动设计。 DDD 有一个规范的概念：

... 用于特殊目的的类似谓词的显式 VALUE OBJECTS。 SPECIFICATION 是确定对象是否满足某些标准的谓词。

我认为快速失败是一回事，另一个是保留验证逻辑的地方。 域是保留逻辑的正确位置，我认为域对象上的规范对象或验证方法将是一个好位置。

Answer 8

我喜欢实现IDataErrorInfo并将我的验证逻辑放在它的 Error 和 this[columnName] 属性中。 这样，如果您想以编程方式检查是否有错误，您可以简单地在代码中测试这些属性中的任何一个，或者您可以将验证交给 Web 窗体、Windows 窗体或 WPF 中的数据绑定。

WPF 的“ValidatesOnDataError”绑定属性使这特别容易。