上下文验证

在我写作的努力中，我一直打算写一些关于验证的材料。这是一个容易引起很多困惑的领域，对一些有效技术的描述会很有帮助。然而，生活中有很多东西可以写，比时间允许的要多得多。

最近的一些阅读让我想到在该主题上说一些初步的话。我看到人们做的一件常见的事情是为对象开发验证例程。这些例程以各种方式出现，它们可能在对象中或外部，它们可能返回一个布尔值或抛出一个异常来指示失败。但我认为始终困扰人们的一件事是，当他们认为对象有效性以一种与上下文无关的方式，例如 isValid 方法所暗示的那样。

我认为，将验证视为与上下文相关的更有用，通常是你想执行的操作。这个订单是否有效以供填写，这个客户是否有效以供入住酒店。因此，与其使用像 isValid 这样的方法，不如使用像 isValidForCheckIn 这样的方法。

其结果之一是，将对象保存到数据库本身就是一个操作。以这种方式思考会引发一些重要的问题。当人们谈论无上下文有效性时，他们通常是指将其保存到数据库中。但是，构成此的各种有效性检查应该用问题“如果此测试失败，是否应该阻止保存？”来进行询问。

在 About Face 中，艾伦·库珀主张我们不应该让我们的有效状态理念阻止用户输入（和保存）不完整的信息。几天前，当我阅读吉米·尼尔森正在撰写的一本书的草稿时，我想起了这一点。他提出了一项原则，即你应该始终能够保存一个对象，即使它存在错误。虽然我不相信这应该是一条绝对规则，但我确实认为人们往往比应该的更阻止保存。考虑验证的上下文可能有助于防止这种情况。

2011年11月3日重新发布