Validation 问题域

• 谁来做Validation
• 何时做Validation
• 如何表达错误
• 如何传递错误
• 如何关联错误到发生错误的对象, 尤其是对象图中非Root对象

这里的Validation指的是对进入到系统中的业务数据的校验(不包括Web应用中页面数据在浏览器端的验证)

谁来做Validation

数据的有效性不是自身所能决定的, 而是使用它的场景(Context)决定的, 因此, 每个Context应该有自己的Validation逻辑.

一个例子, 个人信息残缺, 比如婚姻状况没填, 但联系地址电子邮件等信息完备, 那么这个个人信息到底是合法还是非法? 如果你的应用是个税务相关的应用必须知道婚姻状况则数据是非法的, 如果你的应用是CRM系统有客户的联系方式即可而婚姻状况是可选的则数据就是合法的. 问题是你的应用是税务应用但同时支持客户关系管理, 那这段数据到底合法非法? 税务应用只是年底的时候才有人用, 而客户关系管理系统随时都有人用, 假设数据是通过页面提交的, 那这批数据到底该拒绝还是接受?

何时做Validation

通常有几个时机, 对象被创建出来, 对象状态改变, 以及对象被持久化. 企业应用中同一份数据一般至少有两种存在形式: 在数据库中的持久化状态, 以及在内存中以编程语言定义的对象形式存在. 那么几个时机:

• 手动创建对象, 就是应在构造函数中做验证
• 框架帮忙创建对象, 比如从页面Form绑定到Server端的对象时, 可以在绑定完成的那一刻做校验
• 存到数据库里那一刻

这就带来一个问题: 可能要在三个地方做大体相同的验证, 如何复用验证规则?
另一个问题是: 在引入ORM的应用中, 编程语言写好的验证逻辑同样可以应用在持久化到数据库的那一颗, 那在SQL/DDL语句中定义的约束是否还必要?

如何表达错误

有两个约束:

• 要提供易于用户和支持人员理解的错误信息
• 要提供尽可能丰富的信息

常见的手段是用字符串或者错误代码/ID, 这是不work的, 因为它们合并了错误本身和错误的表示:

出错的地方可能距离需要展现错误的地方很远, 或者有多种展现错误的界面, 或者有很多显示方面的需求, 比如支持国际化, 报错的地方是没有能力也不需要知道错误是如何被展示的, 它要做的是尽可能报告关于错误的详细信息, 包括违反了什么规则, 出错的字段, 实际的值和期待的值等, 字符串和错误代码/ID是没有如此丰富的表达能力的

我们可以用对象来表达错误信息, 对象的类型可以表示错误的类别, 对象的属性/字段可以携带各种与错误类型相关的数据. 然后在需要展现给用户的那一刻, 再把对象翻译成针对那个界面的显示, 比如可以做国际化, 或者提供给程序员更技术化的描述. 而在错误信息需要被显示之前, 错误在系统中的传递, 都是以对象的形式进行的...

听起来跟异常Exception很像?

几个反例是.Net平台上的异常, 比如KeyNotFoundException, 它就不告诉你那个找不到的Key是啥, 还有Index越界, 就不告诉你index的值是多少, 还有数据库连接超时或者Transaction Timeout,死活不告诉你它等了多久超时的, 让你搞不清楚是你的超时时间设的太短还是根本你的设置就没生效

如何传递错误

收集参数, 输出参数, Thread Local, 或者抛出异常然后合适的层次捕获

如何关联错误到发生错误的对象图, 尤其是对象图中非Root对象

给错误一个Key, 这个Key应该能表示出错的对象在对象图中的位置, 比如Key可以是字段名称中间用"."分隔, 级联起来的字符串. 注意这种形式的key应该是在调用验证逻辑的地方组装起来的, 而不应该是验证逻辑本身, 因为验证逻辑通常并不知道自己验证的这个对象在父对象中的字段名称

一个额外的话题

 

很多验证框架采用了基于Attribute/Anontation的方式, 这样当一个对象在不同的Context有不同的验证逻辑时就会很纠结, 因为它是以侵入的方式写到对象的定义中的. 这恰恰从另一个角度说明了对象是不应该跨Context复用的, DCI才是王道