■ 验明正身 - 数据有效性
世界杯万人瞩目但门票有限，所以有人造假有人买假，安联球场的大门前站几位检票员必不可少，而我们的程序有时也一样。当你接到一个累积数年的数据表时，发现单单联系电话都有23种格式时，你是否也感叹到，在用户提交数据时系统也需要靠检票员来验证一下？可是我们还是发现象数据验证这样的内容往往容易被人忽视，许多系统常让拿着公车票的家伙混进球场撒野，各种数据如同发情野马一般长驱直入，先不说安全问题，从数据有效性的角度看，几年后它会象霉菌一样让整个数据库腐烂变质，垃圾成堆。不过常会有另一种声音在耳旁响起："搞那么复杂做什么呀，这个系统、甚至是这个企业没等霉菌开始起作用，它就挂了！"
应用程序必须确保系统的数据有效性有二层含义：一是格式验证，要确保数据属于系统设计时定义的类型、范围，甚至是行业的特定格式，这通常在系统的UI层来完成验证；二是逻辑验证，数据间往往符合特定的业务逻辑规则，数据操作不能破坏其间逻辑关系而造成系统异常，这通常在系统的底层来完成验证。本文主要讨论前者的实现。
不过许多系统为了保持数据有效性常常矫枉过正，界面充斥着拥有复杂输入格式限制的文本输入框，要求用户花费大量时间来进行自我数据校正，填写个表单比高考画框框还要让人费劲，企业用户还好办些，最多抗议两声也就接受，互联网用户可不吃这一套，来点创意！
■ 检票的老太太们 - 验证器架构
WEB应用程序是基于表单来输入数据。为了确保数据有效性，我们必须在服务端对输入数据进行检验，但考虑到用户感受，往往又在客户端插入些javascript脚本。客户端验证就像我们呼吸空气时的鼻子，先把颗粒物杂质等阻挡在外面，从而大大减轻了肺的负担；服务器端验证是构建安全Web应用程序必需的，只有服务器端验证才可以提供真正应用程序级的安全。双重校验，琐碎无聊，怪不得没几人喜欢。
.NET首先将验证器与验证对象分离成两个部份，验证对象暴露验证属性，检票员们分头监督验证对象，完成数据校验，比较复杂的校验可以让几位检票员一起守着；每个页面需要一位领头，让她拿着名单，依次催促页面内每个验证器对所辖输入域进行验证，汇总出结果；最后页面需要某些控件能够自动触发验证，这个角色通常是由带有回发功能的Button类控件来扮演，如图13-1所示。
参与Web窗体验证的服务器控件必须实现IValidator接口，这是检票员们的共同特征。用Volidate方法完成校验过程，得出一个结果值IsValid属性，包含拒绝放行的理由ErrorMessage属性。于是有如下定义：
string ErrorMessage{set;get;}
bool IsValid{set;get;}
void Volidate{};
}
作为校验行为的原子触发单位，页面类设置了一些必要的成员：Page.Validators集合是页面的验证器容器，Page.Validate方法将依次调用容器中每个验证器的Validate方法更新各自的IsValid属性，Page.Valid属性用于汇总页面的校验结果，它就是页面的心灵之锁。
CausesValidation属性是引起回发控件的公共属性，为真时控件在Click事件处理之前自动调用Page.Validate方法，这样使得我们在大多时候不需要显式地去调用Page.Validate方法即可完成校验过程。
■ 模范 - BaseValidator类及客户端验证
尽管在ASP.NET中，任何通过实现IValidate接口的类都可以被认为是验证器，但在实际应用中，我们通常把验证器设计成服务器控件。
BaseValidator是派生自Label类的抽象基类，除了实现IValidator接口，主要执行校验必需的各种通用任务，包括从被验证对象提取值、定义校验抽象方法、产生客户端验证脚本、完成在Page.Validators集合中注册等等。通过继承它，我们只要集中精力去实现服务器端和客户端的验证逻辑就可以实现自定义验证器。下例为一检查CheckBoxList是否有勾选1个以上的自定义验证器范例。
using System;
using System.Collections;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.ComponentModel;
namespace essay.Controls{
//派生于BaseValidator基类的自定义验证器
public class RequiredCheckBoxListValidator : BaseValidator {
private ListControl m_ListCtl;
//启用客户端验证
public RequiredCheckBoxListValidator(){
base.EnableClientScript = true;
}
//确定由ControlToValidate指定的被验证控件是否有效
protected override bool ControlPropertiesValid(){
Control webControl = this.FindControl(ControlToValidate);
if (webControl != null){
m_ListCtl = (ListControl)webControl;
return true;
}
else
return false;
}
//定义校验规则
protected override bool EvaluateIsValid(){
return (m_ListCtl.SelectedIndex != -1);
}
protected override void OnPreRender(EventArgs e) {
if (this.EnableClientScript) this.GenerateScript();
base.OnPreRender(e);
}
//产生并向页面注入客户端验证脚本
protected void GenerateScript(){
StringBuilder sb_Script = new StringBuilder();
sb_Script.Append("");
this.Page.RegisterClientScriptBlock("RBLScript", sb_Script.ToString());
//通过设置验证器的evaluationfunction attribute来指定其客户端验证逻辑
this.Attributes["evaluationfunction"] = "cb_vefify";
}
}
}
正则表达式被用于描述某一类特定格式的字符串方法，能简洁地、能几何倍数地改善文本处理效率，但它不招人疼所以让人厌恶，原因并不是概念有多高深，主要是它长得太丑！一个字符串是否符合某一类特定格式的字符串，关键在于它是否符合这个特定格式的多个匹配规则。
理解正则表达式的钥匙在于提炼每条匹配规则的三个要素：字符子集、重复次数与位置。例字符串"两位数字开头三位英文字母结尾"，写正则表达式之前需要我们这么变换句式："开头 数字{2位} 任意字符{0或多位} 字母{3位} 结尾"，正则表达式为"^ [0-9]{2} [\s\S]* [a-zA-Z]{3} $"。
在每条匹配规则中，可能出现的字符子串有个范围，属于固定的字符子集，正则表达式用常量、区域和逻辑运算来表示这个集合，如图13-2所例，值得注意是部份字符已被定义成元字符，具有特殊的含义。
每条匹配规则中，其字符子集可能出现重复，可以用两种方法表示：一是紧跟着字符子集后加个大括号，内标数字，另一种用元字符表示，如图13-3例。每条匹配规则中字符子集的位置由其在正则表达式中的位置决定，整个字符串开头用"^"表示，结尾用"$"表示。
在很多时候，两条或以上的匹配规则可能要用到同一个字符子集，如html标记中，标签声明应当是同一字符子集，比如"
正则表达式的应用范围很广，除了数据校验外，UBB论坛、页面动态转静态、搜索技术等时常出现它的身影，"我很丑可是我很能干"，在这里我们仅仅只是探讨表达式的书写方法。最后用两个实例总结，如图13-4所示。