深入讲解 ASP+ 验证

答案：     深入讲解 ASP+ 验证
  Anthony Moore 
  Microsoft Corporation 
  
  摘要：有关使用 ASP+ 验证 Web 控件的详细讲解。
  
  目录 
  
  
  简介 
  入门 
  何时发生何事？ 
  服务器端的验证序列 
  客户端的验证 
  有效性规则和有用的错误信息 
  Enabled、Visible 和 Display 属性的作用 
  CustomValidator 控件 
  哪些控件可以被验证？ 
  到此为止
  
  
  --------------------------------------------------------------------------------
  
  
  简介 
  
  这篇文章详细讲解了 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 控件的页面时，了解事件序列非常有效。如果某个验证条件是可选的，您需要准确了解客户机和服务器上何时进行验证。如果要自己编写验证例程，可能会非常耗时，或者有副作用。同时，了解调用验证例程的时机也很重要。
  
  首先，让我们看一下服务器。
  
  
  服务器端的验证序列 
  
  了解页面的有效期非常重要。如果习惯于在 Visual Basic 或类似功能齐全的客户机工具中处理表单，则需要花一定的时间来了解。页面和页面上的所有对象并非在与用户交互时一直有效，尽管有时表面上是这样。 
  
  以下是在第一次访问某个页面时一个简化的事件序列： 
  
  基于 ASPX 文件创建页面及其控件。 
  触发 Page_Load 事件。 
  页面和控件属性保存在一个隐藏字段中。 
  页面和控件转换到 HTML。 
  丢弃所有内容。 
  现在，当用户单击某个按钮或类似控件时，将返回服务器，然后执行一个类似的事件序列。该序列称为返回序列： 
  
  基于 ASPX 文件创建页面及其控件。 
  从隐藏字段恢复页面和控件属性。 
  根据用户输入更新页面控件。 
  触发 Page_Load 事件。 
  触发更改通知事件。 
  页面和控件属性保存在一个隐藏字段中。 
  页面和控件转换到 HTML。 
  再次丢弃所有内容。 
  我们为什么不将所有对象保留在内存中呢？因为使用 ASP+ 建立的 Web 站点无法处理数量非常大的用户。因此，服务器的内存中只保留马上要处理的内容。
  
  何时进行服务器端验证？在第一次获取页面信息时，根本不会进行服务器端验证。大多数最终用户都非常认真，我们允许用户自己确认在表单中填写的信息是否正确，然后我们再使用红色的文字通知用户填错的信息。
  
  在返回事件序列中，第 3 步和第 4 步之间会进行验证。也就是说，进行验证是在来自用户的数据装回控件属性后，但在大多数代码执行之前。这意味着在编写用户事件代码时，通常可以利用已经进行的验证。一般情况下，您都会希望这样做。
  
  在该时刻进行验证的缺点是：如果您要通过编程来修改某些影响该验证的属性，该时刻就太迟了。例如，您会发现，如果通过编写代码来启用或禁用验证控件或更改验证控件的属性，在下一次处理该页之前，不会看到任何影响。通过以下两种方法可以避免这个问题：
  
  在进行验证之前修改属性。 
  在属性更改之后重新验证控件。 
  这两种方法均需要使用在 Page 对象上有效的验证属性和方法。
  
  页面 API 
  
  Page 对象包含一些与服务器端验证有关的重要属性和方法。表 1 中总结了这些属性和方法：
  
  表 1. Page 对象的属性和方法
  
  属性或方法 说明 
  IsValid 属性 这是最有用的属性。该属性可以检查整个表单是否有效。通常在更新数据库之前进行该检查。只有 Validators 集中的所有对象全部有效，该属性才为真，并且不将该值存入缓存。 
  Validators 属性 该页所有验证对象的集合。这是实现 IValidator 界面的对象的集合。 
  Validate 方法 在验证时调用的一种方法。在 Page 对象上默认的执行方式是转至每个验证器，并要求各验证器自行评估。 
  
  
  Validators 集合对于许多任务都非常有用。该集合是实现 IValidator 界面的对象的集合。我之所以使用对象这个词，而不是使用控件，是因为 Page 对象只关注 IValidator 界面。既然所有的验证器通常都是用来实现 IValidator 的一些可视化控件，那么任何人都应能够使用任意的验证对象，并将验证对象加入页面中。 
  
  IValidator 界面包含以下属性和方法：
  
  表 2. IValidator 界面的属性和方法
  
  属性或方法 说明 
  IsValid 属性 指出单独的验证对象进行的有效性检查是否已经通过。您可以在验证后手工更改该值。 
  ErrorMessage 属性 介绍验证对象要验证的错误以及可能会向用户显示的错误。 
  Validate 方法 对验证对象执行有效性检查，以更新其 IsValid 值。 
  
  
  您可以使用该界面执行一些有趣的任务。例如，要将页面重置为有效的状态，请使用以下代码（如 C# 中的示例所示）：
  
      IValidator val;
      foreach(val in Validators) {
          Val.IsValid = true;
&nb

上一个：asp.net 入门的五个步骤
下一个：第九章 配置和调度