ASP.NET入门随想之检票的老太太

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

　　■ 验明正身 - 数据有效性

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

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

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

　　■ 检票的老太太们 - 验证器架构

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

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

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