ASP.NET入门随想之检票员：验证器架构(1)

图1

【引自老燕的博客】德国足协告诫那些可能前往德国观看2006年世界杯赛的球迷要提防假票，不要从非代理商和票贩子手中购票。世界杯门票都是高科技产品，门票被植入微芯片，只有通过合法途径取得门票的球迷才能入场。假票现象在近些年的足球大赛上泛滥成灾，德国足协希望能通过宣传避免世界杯球迷成为其受害者。

验明正身 - 数据有效性

世界杯万人瞩目但门票有限，所以有人造假有人买假，安联球场的大门站几位检票员必不可少。当你接到一个累积数年的数据表，发现单单联系电话都有23种格式时，你是否也感叹到，在用户提交数据时系统也需要靠检票员来验证一下？可是我们还是发现象数据验证这样的内容往往容易被人忽视，许多系统常让拿着公车票的家伙混进球场撒野，各种数据如同发情野马一般长驱直入，先不说安全问题，从数据有效性的角度看，几年后它会象霉菌一样让整个数据库腐烂变质，垃圾成堆。不过常会有另一种声音在耳旁响起：“搞那么复杂做什么呀，这个系统、甚至是这个企业没等霉菌开始起作用，它就挂了！”

应用程序必须确保系统的数据有效性有二层含义：一是格式验证，要确保数据属于系统设计时定义的类型、范围，甚至是行业的特定格式，这通常在系统的UI层来完成验证；二是逻辑验证，数据间往往符合特定的业务逻辑规则，数据操作不能破坏其间逻辑关系而造成系统异常，这通常在系统的底层来完成验证。本文主要讨论前者的实现。

不过许多系统为了保持数据有效性常常矫枉过正，界面充斥着拥有复杂输入格式限制的文本输入框，要求用户花费大量时间来进行自我数据校正，填写个表单比高考画框框还要让人费劲，企业用户还好办些，最多抗议两声也就接受，互联网用户可不吃这一套，来点创意！

.NET的检票员们 - 验证器架构

Web应用程序是基于表单来输入数据。为了确保数据有效性，我们必须在服务端对输入数据进行检验，但考虑到用户感受，往往又在客户端插入些javascript脚本。客户端验证就像我们呼吸空气时的鼻子，先把颗粒物杂质等阻挡在外面，从而大大减轻了肺的负担；服务器端验证是构建安全Web应用程序必需的，只有服务器端验证才可以提供真正应用程序级的安全。双重校验，琐碎无聊，怪不得没几人喜欢。

.NET首先将验证器与验证对象分离成两个部份，验证对象暴露验证属性，检票员们分头监督验证对象，完成数据校验，比较复杂的校验可以让几位检票员一起守着；每个页面需要一位领头，让她拿着名单，依次催促页面内每个验证器对所辖输入域进行验证，汇总出结果；最后页面需要某些控件能够自动触发验证，这个角色通常是由带有回发功能的Button类控件来扮演，如图13-1所示。

图2

参与Web窗体验证的服务器控件必须实现 IValidator接口，这是老太太们的共同特征。用Volidate方法完成校验过程，得出一个结果值IsValid属性，包含拒绝放行的理由ErrorMessage属性。于是有如下定义：

public interface IValidator{
string      ErrorMessage{set;get;}
bool        IsValid{set;get;}
void        Volidate{};
}

作为校验行为的原子触发单位，页面类设置了一些必要的成员：Page.Validators集合是页面的验证器容器，Page.Validate方法将依次调用容器中每个验证器的Validate方法更新各自的IsValid属性，Page.Valid属性用于汇总页面的校验结果，它是页面的心灵之锁。

CausesValidation属性是引起回发控件的公共属性，为真时控件在Click事件处理之前自动调用Page.Validate方法，这样使得我们在大多时候不需要显式地去调用 Page.Validate方法即可完成校验过程。