ASP.NET 2.0服务器控件之实现验证控件

2. 验证控件实现机制

　　通常情况下，使用ASP.NET 2.0的5个内置验证控件，可以满足多数应用程序的需要。然而，为了提高开发的灵活性，满足不同Web应用的需求，ASP.NET 2.0内置了一个可扩充的验证框架。该框架定义了服务器端和客户端的基本实现规则。开发人员可以使用这个可扩充的验证框架，根据应用需要设计自己的验证控件来实现新的设计规则。

　　(1)服务器端实现机制

　　并非所有的Web服务器控件都支持验证控件。可以使用验证控件进行验证的标准控件包括:TextBox、ListBox、DropDownList、RadioButtonList、HtmlInputText、HtmlInputFile、HtmlSelect和HtmlTextArea、FileUpload和HtmlInputPassword等。这些支持验证控件的控件有一个共同特征，即元数据中包含System.Web.UI.ValidationPropertyAttribute。ValidationPropertyAttribute定义了控件用于标识验证属性的元数据特性。除此之外，如果由以上控件派生的自定义控件类，需要支持验证，那么必须在控件类前定义ValidationPropertyAttribute，这样该控件才能作为验证目标控件。开发人员在实现自定义验证控件过程中，必须首先了解以上所介绍的验证目标控件内容，然后才能更好的开发控件。

　　为了实现自定义验证控件，ASP.NET 2.0提供了3个重要对象:(1)System.Web.UI.IValidator;(2)System.Web.UI.WebControls.BaseValidator;(3)System.Web.UI.WebControls.CustomValidator。以上三者之间联系紧密，由它们组成的验证框架具有很强的灵活性和可扩充性。IValidator接口是验证框架的基础，任何实现该接口的类都可以作为验证程序。BaseValidator是抽象基类，该类实现IValidator接口，并继承System.Web.UI.WebControls.Label控件。通常情况下，自定义验证控件都派生自该类。CustomValidator实际是一个验证控件，开发人员可以用它来添加自定义的验证逻辑。为了更好的说明验证框架，下面将逐一介绍以上3个对象。

　　IValidator接口的定义如下:

public interface Ivalidator { 　string ErrorMessage {get; set;} 　bool IsValid {get; set;} 　void Validate(); }

　　IValidator接口的成员包括1个方法和2个属性。ErrorMessage属性用于获取或设置条件验证失败时生成的错误信息。IsValid属性当由类实现时，获取或设置一个值，通过该值指示用户在指定控件中输入的内容是否通过验证。Validate方法由类实现时，计算它检查的条件并更新IsValid属性。对于开发人员来讲，如果实现的是一个普通验证程序，而非验证控件，那么可以通过实现该接口来完成。其原因在于验证框架的实现分布在Page类、BaseValidator类和验证目标控件中。这些类之间的相关性不允许任意实现IValidator接口。对于实现自定义验证控件，推荐的方法是继承BaseValidator类。

　　BaseValidator是验证框架中最为重要的部分。该类派生自Label类，并且实现IValidator接口。无论是内置验证控件，还是自定义验证控件，都必须派生自BaseValidator类。该类实现所有验证控件都必须实现的通用属性。下面介绍了一些常用验证属性。

　　· ControlToValidate属性

　　该属性值为String类型，其用于验证控件将计算的输入控件的编程ID。如果此为非法ID，则引发异常。

　　· Display属性

　　该属性值为ValidatorDisplay类型，其用于指定的验证控件的显示行为。此属性可以为下列值之一:(1)None—验证控件从不内联显示。如果希望仅在ValidationSummary控件中显示错误信息，则使用此选项。(2)Static—如果验证失败，验证控件显示错误信息。即使输入控件通过了验证，也在Web页中为每个错误信息分配空间。当验证控件显示其错误信息时，页面布局不变。由于页面布局是静态的，同一输入控件的多个验证控件必须占据页上的不同物理位置。(3)Dynamic—如果验证失败，验证控件显示错误信息。当验证失败时，在页上动态分配错误信息的空间。这允许多个验证控件共享页面上的同一个物理位置。注意:由于验证控件的空间是动态创建的，所以页面的物理布局会发生更改。为了防止页面布局在验证控件变得可见时更改，必须调整包含验证控件的HTML元素的大小，使其大得足以容纳验证控件的最大大小。

　　· ErrorMessage属性

　　该属性值为String类型，其用于当验证失败时，在ValidationSummary控件中显示的错误信息。如果未设置验证控件的Text属性，则验证失败时，验证控件中仍显示此文本。ErrorMessage属性通常用于为验证控件和ValidationSummary控件提供各种消息。注意:此属性不会将特殊字符转换为HTML实体。例如，小于号字符(<)不转换为&lt;。这允许将HTML元素(如＜IMG＞元素)嵌入到该属性的值中

　　· IsValid属性

　　该属性值为bool类型，其用于指示ControlToValidate属性所指定的输入控件是否被确定为有效。

　　由该类派生的验证控件，可以不必再次实现以上通用属性，而只要根据应用需要另外定义一些属性和验证逻辑即可。例如，对于RangeValidator控件，除具有以上通用属性外，还定义了用于限定取值范围的MinimumValue和MaximumValue属性，以及用于指定要比较的值的数据类型的Type属性。此外，该控件的验证逻辑是通过重写BaseValidator.EvaluateIsValid方法实现的。由此看来，BaseValidator简化了自定义验证控件的实现过程，为控件开发人员提供了方便。

　　CustomValidator派生自BaseValidator类，它是5个内置验证控件之一。通常情况下，页面开发者使用CustomValidator来添加自定义的验证逻辑，这只要通过定义ServerValidate事件的事件处理方法以及ClientValidationFunction属性来完成。由于CustomValidator不提供复用机制(访问属性为public)，因此自定义验证控件不能自该类派生。

　　(2)客户端实现机制

　　上文介绍了为实现验证控件，开发人员必须掌握的3个核心对象。掌握这些对象的定义和使用方法对于开发验证控件具有重要意义。通过它们，我们可以在服务器验证中添加验证逻辑。当页面回传时，验证目标控件的输入数据被发往服务器端参与验证逻辑。如果输入数据不能满足验证条件，那么页面将重新呈现，并且要求用户再次进行输入。整个验证过程可能需要多次往返，这样必然降低应用程序的易用性，并给服务器增加负担。

　　为了解决以上问题，开发人员必须学会为验证控件添加客户端验证机制。如果用户的浏览器支持DHTML和JavaScript技术，并且页面和验证控件的EnableClientScript均设置为true，那么就可以在客户端执行验证。客户端验证通过在向服务器发送用户输入前，检查用户输入、改变一些页面效果来增强验证过程。例如，通过在客户端检测输入错误，从而避免服务器端验证所需要的信息来回传递。服务器端验证总是要被执行的，这看起来好像是与客户端验证产生了重复，实际不然。出于安全考虑，如果某些用户通过手工提交恶意数据，而绕过客户端验证，那么服务器端验证的执行将对保护应用程序的安全性，甚至为服务器的安全性提供有力支持。

　　在ASP.NET 2.0中，如果开发人员使用内置验证控件实现验证功能，那么ASP.NET 2.0将自动产生相关的JavaScript代码。如果开发人员查看相关HTML源代码，那么将会发现有些来自WebResource.axd的JavaScript文件链接。然而，我们是无法查看相关文件代码的。这一点与ASP.NET 1.x不同。在ASP.NET 1.x中，默认情况下，在目录“C:\Inetpub\wwwroot\aspnet_client\system_web\版本号”中包含一个WebUIValidation.js文件。该文件中包括了实现客户端验证的JavaScript代码。开发人员可以通过阅读这些代码来了解验证功能的具体实现方法。ASP.NET 2.0中没有存在相关的源代码文件，而是通过WebResource.axd等机制来实现。

　　有关实现客户端验证的内容，主要涉及实现客户端功能等知识。这些内容在前面的文章中已经详细进行了讲解。有兴趣的读者可阅读有关文章。

　　3. 小结

　　本文主要介绍了内置验证控件，以及自定义验证控件实现机制。实际上，如果读者开发自行实现验证控件时，将会发现这个过程需要很多知识。例如，服务器端编程语言、JavaScript、CSS、DHTML等等。因此，如果读者希望创建高质量的验证控件，那么不仅要了解相关知识，而且必须达到精通的水平。

查看本文来源