页面的处理指令
页面指令的处理用于配置执行该页面的运行时环境。在ASP.NET中，指令可以位于页面的任何位置，但良好且常见的习惯是将其置于文件的开始部分。除此，页面指令的名称是不区分大小写的，且指令的属性(attribute)值也不必加引号。@Page是ASP.NET中最重要的也是最常用的指令。表3.4列出了所有ASP.NET指令。 【101～102】
表3.4 ASP.NET页面支持的指令
|
指 令
|
说 明
|
|
@Assembly
|
用于将程序集链接到当前页面或用户控件上
|
|
@Control
|
用于定义控件特有的属性(attribute)，这些属性会控制控件编译器的行为
|
|
@Implements
|
用于指示当前页面或当前用户控件实现指定的.NET Framework 接口
|
|
@Import
|
用于显式地将命名空间导入到页面或用户控件中
|
|
@Master
|
用于指示将当前页面标识为ASP.NET母版页(详见第6章)。ASP.NET 1.x不支持该指令
|
|
@MasterType
|
当通过Master属性(property)访问ASP.NET母版页时，它会为该母版页提供一种创建强类型引用的方式(详见第6章)。ASP.NET 1.x不支持该指令
|
|
@OutputCache
|
用于控制页面或用户控件的输出缓存策略(详见第16章)
|
|
@Page
|
用于定义页面特有的属性，以便控制处理该页面的页面编辑器和语言解析器的行为
|
|
@PreviousPageType
|
提供了一种获取之前的页面强类型引用的方式，通过PreviousPage属性便可以对之前的页面进行访问
|
|
@Reference
|
用于将页面或用户控件链接到当前页面或用户控件上
|
|
@Register
|
用于在页面或控件中创建自定义标签。新的标签(包括前缀和名称)会将命名空间和用户定义的控件关联起来
|
除@Page、 @PreviousPageType、@Master、@MasterType和@Control外，所有指令都可以在页面和控件中声明。@Page和 @Control是互斥的：@Page仅能用在.aspx文件中，而@Control指令仅能用在.ascx文件中。@Master用于定义一种非常特殊的页面——母版页(master page)。
处理指令的语法较特殊，但对于所有指令类型都是一致的。多个属性(attribute)必须用空白分割，属性与值间的等号(=)两边不能有空白，如下所示：
<%@ Directive_Name attribute="value" [attribute="value" … ] %> 【103】
每种指令都有自己类型化的属性集合。将错误类型的值赋给一个属性，或在某个属性中使用错误的属性，都会导致编译错误。
要点：指令的属性内容总是以纯文本的形式被解析。然而，对于某些属性，应包含能够被解析为特定.NET Framework类型的值。当ASP.NET页面被解析时，所有指令属性
会被提取，并存储在一个字典中。属性的名称和数目必须与该指令所对应模式相匹配。只要用字符串表示的属性值能够被转换为目标类型，那么它便是有效的。例如，如果某个属性只接受布尔(Boolean)类型的值，则只有true和false是有效的。
@Page指令
@Page指令只能在.aspx页面中使用，若在其他ASP.NET页(如控件和Web服务)中使用，会导致编译错误。每个.aspx文件最多只能包含一个@Page指令。虽然从语法的角度看，没有必要强制要求指定该指令，但实际几乎所有复杂的页都这样做。
@Page指令大约有30个属性，它们从逻辑上可以分为三类：编译(详见表3.5)、页面整体行为(详见表3.6)和页面输出(详见表3.7)。每个ASP.NET页在第一次请求时进行编译，实际发送给浏览器的HTML是类的方法生成的，而这些类也是动态生成的。表3.5所列的属性用于对编译器参数进行调整，并能够选择要使用的语言。
表3.5 用于页面编译的@Page指令属性
|
属 性
|
说 明
|
|
ClassName
|
用于指定页面被请求时动态生成的类的名称。它必须是不带命名空间信息的类名
|
|
CodeFile
|
用于提示当前页面代码隐藏类的路径。该类文件必须被部署到Web服务器上。ASP.NET 1.x不支持该属性
|
|
CodeBehind
|
Visual Studio .NET 2003使用的属性，用于提示当前页面代码隐藏类的路径。该类文件会被编译为可部署的程序集(对2.0或更高版本的ASP.NET来说，应使用 CodeFile属性)
|
|
CodeFileBaseClass
|
用于指定页的基类及其关联的代码隐藏类的基类名称。该属性是可选的，但如果使用了CodeFile属性，则必须指定该属性。ASP.NET 1.x不支持该属性
|
|
CompilationMode
|
用于指示当前页面是否在运行时编译。ASP.NET 1.x不支持该属性
|
|
CompilerOptions
|
用于编译当前页的一系列编译器命令行参数
|
|
Debug
|
一个布尔值，用于指示是否应使用调试符号编译该页
|
|
Explicit
|
一个布尔值，用于确定在编译该页时是否将Visual Basic的Option Explicit模式设置为On。Option Explicit会强制编程人员显式声明所有变量。如果当前页所选语言不是Visual Basic .NET，该属性将被忽略
|
|
Inherits
|
用于定义当前页要继承的基类，它可以为从Page类派生的任何类
|
|
Language
|
用于在编译时提示内联代码块(<% … %>)和<script>区段中代码所使用的语言。支持的语言包括Visual Basic .NET、C#、JScript .NET和J#。如果没有另外指定，则采用默认设置Visual Basic .NET
|
续表
|
属 性
|
说 明
|
|
LinePragmas
|
用于确定运行时是否应在源代码中生成行杂注(line pragma)
|
|
MasterPageFile
|
用于指示当前页面的母版页。ASP.NET 1.x不支持该属性
|
|
Src
|
用于指示包含实现Inherits指定的基类的源文件路径。Visual Studio和其他快速应用程序开发(RAD)设计器不使用该属性
|
|
Strict
|
一个布尔值，用于确定在编译当前页时，是否将Visual Basic的Option Strict设为On。若开启Option Strict，则只允许类型安全的转换，禁止可能导致数据丢失的隐式类型转换(在这种情况下，其行为与C#一致)。如果当前页所选语言不是Visual Basic .NET，该属性将被忽略
|
|
Trace
|
一个布尔值，用于指示是否开启跟踪功能。如果启用跟踪功能，额外的信息会被追加到页面的输出中。默认值为false
|
|
TraceMode
|
当启用跟踪功能时，提示当前页面跟踪消息的显示方式。有效值为SortByTime和SortByCategory。若跟踪功能开启，该属性的默认值为SortByTime
|
|
WarningLevel
|
提示编译器的警告级别，当到达指定的级别时，编译过程将中止。有效值为0～4
|
【104～105】
注意，Explicit和Strict属性的默认值从应用程序的配置文件中读取。通过合并所有计算机级、应用程序级和文件夹级的设置，从而获得ASP.NET应用程序的设置。这表明我们还可以控制 Explicit和Strict属性的默认值。如果不更改默认的配置信息(即.NET Framework安装时创建的配置信息)，Explicit和Strict便为默认设置true。如果在各配置文件中，删除与其相关的所有设置，二者的值都会变为false。
可通过表3.6列出的属性在某种程度上控制页的整体行为和支持的功能。例如，我们可以设置自定义的错误页、禁用会话状态，以及控制页面的事物处理行为。
表3.6 用于控制页面行为的@Page指令属性
|
属 性
|
说 明
|
|
AspCompat
|
布尔类型的属性。若设为true，则允许当前页面在单线程单元(STA)线程上执行。该设置使页能够调用COM+ 1.0组件，以及用Visual Basic 6.0开发的需要访问非托管ASP内置对象的组件(第14章将探讨该话题)
|
|
Async
|
如果设置为true，则生成的页面类将派生于IHttpAsyncHandler，而不是使IHttpHandler 将某些内建的非同步功能添加到页中。ASP.NET 1.x不支持该属性
|
续表
|
属 性
|
说 明
|
|
AsyncTimeOut
|
用于定义处理异步任务时使用的超时时间(单位为秒)。默认为45秒。ASP.NET 1.x不支持该属性
|
|
AutoEventWireup
|
布尔类型的属性，用于指示是否启用页面的事件。默认为true。使用Visual Studio .NET开发的页会将该属性设置为false，页面的事件会被分别绑定到处理程序上
|
|
Buffer
|
布尔类型的属性，用于确定是否启用HTTP响应缓冲。默认值为true
|
|
Description
|
用于提供当前页面的文本描述。ASP.NET页解析器会忽略该属性，而只用作文档说明
|
|
EnableEventValidation
|
布尔类型的属性，用于决定是否使当前页面生成一隐含字段，为支持事件数据验证的输入字段做缓冲。默认值为true。 ASP.NET 1.x不支持该属性
|
|
EnableSessionState
|
用于定义当前页面处理会话数据的方式。如果设为true，则可以读/写会话状态。如果设为false，则应用程序无法使用会话数据。最后，如果设为ReadOnly，则只能读取会话数据，而不能更改
|
|
EnableViewState
|
布尔类型的属性，用于指示是否在页面请求间保持视图状态。视图状态是页面调用的上下文，用于保存往返过程之间当前页面状态值的集合(第15章将对此进行讲解)
|
|
EnableTheming
|
布尔类型的属性，用于指示当前页是否对嵌入的控件应用主题。默认值为true。ASP.NET 1.x不支持该属性
|
|
EnableViewStateMac
|
布尔类型的属性，用于指示ASP.NET是否为特定的计算机生成身份验证码，并将其追加到页的视图状态中(除 Base64编码)。属性名中的Mac代表“计算机身份验证检查”(machine authentication check，MAC)。若将该属性设置为true，则在回发时，ASP.NET会检查视图状态的身份验证码，以便确保其在客户端上没有被 篡改
|
|
ErrorPage
|
定义一个目标URL，后者指向一提示页。在页发生未处理异常时，用户会被重定向到该位置
|
|
MaintainScrollPositionOnPostback
|
用于指示是否在回发之后恢复客户端浏览器的滚动条位置。默认值为fasle
|
|
SmartNavigation
|
布尔类型的属性，用于指示当前页是否支持Internet Explorer 5或更高版本的智能导航功能。智能导航使得页面刷新后不会失去滚动位置和元素焦点
|
|
Theme,StyleSheetTheme
|
用于指示为当前页选择的主题(或样式表主题)名称。ASP.NET 1.x不支持该属性
|
续表
|
属 性
|
说 明
|
|
Transaction
|
用于指示当前页是否支持或需要事物。有效的值为：Disabled、NotSupported、Supported、 Required和RequiresNew。默认情况下，事务支持是被禁用的
|
|
ValidateRequest
|
布尔类型的属性，用于指示是否执行请求验证。如果设置为true，ASP.NET将根据一硬编码的潜在危险值列表对所有的输入数据进行检查。该功能有助于降低页面的跨站点脚本攻击风险。默认值为true。ASP.NET 1.0不支持该功能
|
|
ViewStateEncryptionMode
|
用于指示视图状态的加密方式。有三个可能的枚举值：Auto、Always和Never。默认为Auto，这表明只有在控件要求时才加密视图状态。注意，每次请求的页面处理都加密视图数据，会对服务器造成一定的额外开销
|
【106～107】
表3.7中列举的属性用于控制为页面生成的输出信息格式。例如，我们可以设置页面的内容类型，或者尽可能地使输出本地化。
表3.7 用于控制输出的@Page指令属性
|
属 性
|
说 明
|
|
ClientTarget
|
用于指示ASP.NET服务器控件呈现其内容时所要面向的浏览器
|
|
CodePage
|
用于指示相应的代码页值。只有在使用一个代码页创建该页(而不是使用运行该页的Web服务器的默认代码页)时，才设置该属性。在这种情况下，将该属性设置为开发计算机的代码页。代码页是一个符号集合，包括数字、标点和其他符号。不同语言的代码页会有区别
|
|
ContentType
|
用于将响应的内容类型定义为标准的MIME类型。支持任何有效的HTTP内容类型字符串
|
|
Culture
|
用于指示当前页的区域性设置。区域性信息包括书写与排序系统、日历和货币格式。该属性值必须为区域性相关的名称，即它必须包含语言和国家信息。例如，en-US就是一个有效值，而en本身则会被认为是国家不相关的
|
|
LCID
|
32位的值，用于定义页的区域标识符。默认情况下，ASP.NET会使用Web服务器的区域设置
|
|
ResponseEncoding
|
用于指示当前页面的编码方案名称。该值用于设置内容类型HTTP标头的CharSet属性。在内部，ASP.NET会将所有字符串按Unicode处理
|
|
Title
|
用于指示当前页的标题。对于一般的页面作用不大，因为可以使用HTML的<title>标签，该属性的定义是为了帮助开发者在内容页中不能访问<title>的情况下(这取决于母版页的结构设计)，为其设置标题
|
续表
|
属 性
|
说 明
|
|
UICulture
|
用于指定资源管理器(Resource Manager)使用的默认区域信息名称，以便在运行时查找区域性特定的资源
|
不难看出，表3.7中的许多属性与页面的本地化有关。ASP.NET(更一般地讲是.NET Framework)极大地简化了构建多语言的国际化应用程序的任务。第5章会深入探讨该问题。
@Assembly指令
@Assembly指令用于将某个程序集链接到当前页面，使其类和接口可以在该页面上使用。在ASP.NET编译该页时，会有几个默认的程序集被链接进去。因此，只有在需要链接一个非默认程序集时，才应使用该指令。表3.8列出了自动提供给编译器的.NET程序集。 【108】
表3.8 默认链接的程序集
|
程序集文件名
|
说 明
|
|
Mscorlib.dll
|
提供.NET Framework的核心功能，包括类型、AppDomain和运行时服务
|
|
System.dll
|
提供另一组系统服务，包括正则表达式、编译、本地方法、文件输入/输出和网络
|
|
System.Configuration.dll
|
定义了读/写配置文件数据的类。ASP.NET 1.x不包含该程序集
|
|
System.Data.dll
|
定义了数据容器和数据访问类，包括整个ADO.NET框架
|
|
System.Drawing.dll
|
实现了GDI+功能
|
|
System.EnterpriseServices.dll
|
提供允许被服务的组件和COM+之间进行交互的类
|
|
System.Web.dll
|
该程序集实现了ASP.NET核心服务、控件和类
|
|
System.Web.Mobile.dll
|
该程序集实现了ASP.NET核心移动服务、控件和类。.NET Framework的1.0版安装时不包含该程序集
|
|
System.Web.Services.dll
|
包含驱动Web服务运行的核心代码
|
|
System.Xml.dll
|
实现了.NET Framework的XML功能
|
|
System.Runtime.Serialization.dll
|
定义了.NET序列化功能的API。在ASP.NET 2.0应用程序中，该程序集是开发者额外添加的最常用程序集之一。ASP.NET 3.5之前的版本没有引入该程序集
|
|
System.ServiceModel.dll
|
定义了Windows Communication Foundation(WCF)服务的类和结构。ASP.NET 3.5之前的版本没有引入该程序集
|
|
System.ServiceModel.Web.dll
|
定义了ASP.NET和AJAX需要使用的附加类。ASP.NET 3.5之前的版本没有引入该程序集
|
|
System.WorkflowServices.dll
|
定义了工作流(Workflow)和WCF服务需要的类。ASP.NET 3.5之前的版本没有引入该程序集
|
除这些程序集外，ASP.NET运行库还会自动将 Web应用程序Bin子目录中的程序集链接到所有页面上。通过编辑计算机级web.config文件中的设置，可以更改、扩展或限制默认的程序集列表。这种更改将作用于运行在该Web服务器上的所有ASP.NET应用程序。此外，还可以编辑应用程序特定的web.config文件，逐一对每个应用程序的程序集列表进行定制。为防止将Bin目录中存在的所有程序集都链接到页面，可以在根配置文件中删除以下代码：
<add assembly="*" /> 【109】
警示：对于ASP.NET应用程序，整个配置属性集都在计算机级进行了设置。最初，服务器计算机上运行的所有应用程序共享相同的设置。独立的应用程序可以在其自身的web.config文件中重写其中的某些设置。每个应用程序可以在其根目录放置一个web.config文件，在应用程序特定的子目录下放置其他特殊化的web.config副本。每一页的设置取决于从计算机级到当前文件夹路径发现的所有配置文件中的全部设置。在ASP.NET 1.x中，machine.config文件包含完整的默认设置树。而在ASP.NET 2.0中，与Web应用程序有关的设置数据被移到了web.config文件中，与machine.config处于同一系统文件夹。该文件夹叫 CONFIG，位于ASP.NET安装路径下：%WINDOWS%\Microsoft. Net\Framework\[version] 。
要将所需程序集链接到页面，可使用如下语法：
<%@ Assembly Name="AssemblyName" %>
<%@ Assembly Src="assembly_code.cs" %>
@Assembly指令支持两个互斥属性：Name 和Src。Name用于提示链接到页面的程序集名称。该名称不能包含路径和扩展名。Src用于指示要动态编译并链接到页面的源文件路径。 @Assembly指令可以在页面的主体部分出现多次。事实上，对于每个要链接的程序集来说，都需要分别添加指令。Name和Src不能同时在一个 @Assembly指令中使用，但对于页面中定义的不同指令，则可以分别选择。
提示：虽然 Name指向的是一个已存在的且准备加载的程序集，但Name与Src在性能方面的差别很小。使用Src引用的源文件只在首次被请求时编译一次。 ASP.NET运行库会将源文件与动态编译的程序集进行映射，并在源文件被更改前，一直使用已编译的代码。也就是说，在应用程序级的首次调用过后，无论使用Name还是Src，对页面性能的影响都是相同的。
@Import指令
@Import指令用于将指定的命名空间链接到页面，以便所有已定义类型可以在页面访问，而不必使用完全限定名(fully qualified name)。例如，为创建一ADO.NET DataSet类的实例，可以导入System.Data命名空间，也可以像下面这样使用完全限定名：
System.Data.DataSet ds = new System.Data.DataSet(); 【110】
一旦将System.Data命名空间引入当前页，我们就可以像下面这样更自然地编写代码：
DataSet ds = new DataSet();
@Import指令的语法是自描述的：
<%@ Import namespace="value" %>
@Import可以在页面主体中多次使用。 ASP.NET的@Import指令相当于C#的using语句，也相当于Visual Basic .NET的Import语句。回顾非托管的C/C++，可以说该指令所起的作用几乎与#include指令相同。
注意：@Import只能帮助编译器解析类的名称，并不会自动链接所需程序集。使用@Import指令可以缩短类的名称，但倘若包含该类的程序集未被正确地链接，会引发编译器的类型错误。如果程序集尚未被链接，使用“完全限定类名”也无济于事，因为编译器需要类型的定义。您可能已经注意到了，程序集和命名空间的名称往往是一致的。但请记住，这纯属巧合，程序集与命名空间是完全不同的实体，分别需要相应的指令。
例如，为连接SQL Server数据库并获取某些无连接数据，我们需要导入以下两个命名空间：
<%@ Import namespace="System.Data" %>
<%@ Import namespace="System.Data.SqlClient" %>
我们需要System.Data命名空间以便使用 DataSet和DataTable类，而通过System.Data.SqlClient命名空间来准备并发送命令。在这种情况下，我们不需要另外链接程序集，因为System.Data.dll程序集是默认链接的。
@Implements指令
@Implements指令用于指示当前页面实现的.NET Framework中的特定接口。接口是一组逻辑上相关的函数签名，作为各组件暴露其函数集合的一种契约。与抽象类(abstract class)不同，接口不提供代码或执行功能。若在ASP.NET页中实现某个接口，要在<script>区段中定义所需方法和属性。 @Implements指令的语法如下所示：
<%@ Implements interface="InterfaceName" %> 【111】
如果页中需要实现多种接口，@Implements 指令可以在该页中出现多次。注意，如果决定将所有页的逻辑定义在单独的文件中，则不能使用该指令来实现接口，而要在代码隐藏类中进行。
@Reference指令
@Reference指令用于建立当前页与指定页或用户控件间的动态链接。该功能在跨页面通信方面发挥着重大作用。我们可通过它来创建用户控件的强类型实例。让我们来看一下它的语法。
@Reference指令可以多次出现在页面中，并有两个互斥属性：Page和Control。这两个属性都用于指定源文件的路径：
<%@ Reference page="source_page" %>
<%@ Reference control="source_user_control" %>
Page属性用于指向某个.aspx源文件，而 Control属性包含的是.ascx用户控件的路径。在这两种情况下，被引用的源文件都会被动态编译进程序集中，如此一来，在编程时，可以在主动引用页面中使用源文件中定义的类。在运行时，ASP.NET页面是.NET Framework类的实例，带有由方法和属性组成的特定接口。当主动引用页面执行时，被引用页面变为表示.aspx源文件的类，可以按需要对其进行实例化和编码。注意，为使该指令发挥作用，被引用页面必须与主调页面处于一个域中。不允许跨站点调用，且Page和Control属性只接受相对虚拟路径。
