这篇文章具体讲解了 ASP+ 验证控件的工作方法。假如要生成其中包含验证控件的复杂页面，或是要扩展验证框架，建议您阅读本文。假如要学习使用验证控件，或是要决定是否使用验证控件，请参见“ASP+ 中的用户输入验证（英文）”。

入门

我们知道，在整个 ASP+ 开发过程中，了解验证异常重要。看看如今的大多数商业 Web 站点，您会发现，这些站点中有许多表单，这些表单明显是通过执行大量手写的代码来执行验证。编写验证代码并不是一件有趣的工作。假如要通过编写代码来显示数据表或动态生成图表，可能会很吸引人，但是没有人可以向他的同事证明这种很“酷”的方式能够禁止在姓名字段中输入空值。

因为其它一些原因，Web 应用程序的验证也是异常麻烦的。HTML 3.2 对您可以控制的内容或可以从用户处得到的反馈的限制很多，因此无法应用在功能更全的客户机上可以使用的技巧，例如禁止用户输入某些字符，或发出嘀声。使用浏览器脚本可能会产生更强盛的验证。但是这种方式很难得以证明，因为客户浏览器中并非一定有脚本，并且恶意的用户可以绕过。因此，为了保证站点安全，有必要对服务器进行同样的检查。

在开发 ASP+ 时，我们的初衷是只使用一个控件来处理验证，可能本该是一个能够显示错误的 TextBox 控件。可是到了设计该控件时，却发现无法实现这种愿望。我们研究了大量的数据输入表单，试图找到可以适用于尽可能多的表单的一种解决方案。我们发现，数据输入表单具有许多有趣的特性：

尽管错误信息或图标常常与输入元素相邻，但是它们几乎总是位于表的不同单元格中。
页面中常常会有一个区域来汇总所有错误。
许多站点包含客户端脚本，以便提供更快捷的反馈，同时防止白白地在与服务器之间来回。
许多包含客户端脚本的站点在出现错误时会显示信息框。
不仅会验证文本输入，还会验证下拉列表和单选按钮。
假如某个字段为空，站点通常会显示与该条目无效时不同的信息或图标。
许多有效性检查可以很好地代替常用的表达式。
验证通常是基于两个输入之间的比较结果。
90% 或 90% 以上的验证任务是一些常见的操作，例如检查姓名或邮政编码。大多数站点好像仍在重复进行这些工作。
因为站点之间的差别通常太大，无法获得一种完美的解决方案来处理每个站点的所有验证任务。
考虑了上述所有情况，最终获得的解决方案包括五个验证器控件、ValidationSummary 控件以及与 Page 对象的集成。同时很明显，该解决方案需要扩展，在客户机和服务器上均需要有一个 API 来配合。

我们在研究进行的各种验证时发现，我们好像需要一个更大的工具箱。在大多数组件环境中，例如 Microsoft® ActiveX®，我们可能本来试图将所有验证控件的功能集成到一个控件中，处理不同模式下的不同属性。不过，幸好 Microsoft® .NET 框架中有神奇的继续性，可以提供一套控件来对特定的属性进行特定的验证，因为派生每个新控件所需的额外工作量异常小。

这些控件所完成的大多数工作均在其公用的父级 BaseValidator 中实现。您也可以从 BaseValidator 或其它控件派生来完成各项工作。实际上，即使 BaseValidator 都懒得实现其自己的 Text 属性，而是从 Label 属性继续。

何时发生何事？

在处理包含验证 Web 控件的页面时，了解事件序列异常有效。假如某个验证条件是可选的，您需要正确了解客户机和服务器上何时进行验证。假如要自己编写验证例程，可能会异常耗时，或者有副作用。同时，了解调用验证例程的时机也很重要。

首先，让我们看一下服务器。