ASP.NET开发栈

在最高的抽象级别，ASP.NET应用的开发经历两个阶段——ASP.NET页的创作和运行库配置。我们构建形成应用的页面，实现该应用的用户需求，然后细调周围的运行时环境(run-time environment)，使它安全有效地为页面提供服务。

1.3.1  表示层

ASP.NET页面由控件、自由文本(free text)和标记组成。当源代码转换为一个页类的活动实例时，ASP.NET运行库不再进一步区分逐字逐句的文本、标记和服务器控件——一切都是控件，包括文字正文和回车符。运行时，任何一个ASP.NET页只不过是控件的图形   表示。

1. Rich Control

ASP.NET丰富的编程能力源自它那广泛的服务器控件库，该库涵盖了HTML交互的基本任务(例如，通过输入标签收集文本)以及更先进的功能(诸如基于网格的数据显示)。自带的控件集很大，足以实现任何一组需求。此外，ASP.NET的最新版本增加了几个新的Rich Control，可充分发挥开发者的生产率。

在ASP.NET 2.0中，可以找到创建Web向导、分级数据的可折叠视图、高级数据报表、常用窗体、声明式数据绑定、菜单、站点导航等的控件，甚至可以找到一个微小的API来创建类似于门户一样的页。Rich Control的推出，意味着减少了开发时间和编码错误，实现了更多的最佳实践，以及向最终用户提供了更先进的功能。第4章、第6章以及后面的第10章将专门介绍控件。

2. 定制控件

ASP.NET核心控件提供了一整套完备的控件来构建Web功能。通过添加定制控件，可以扩展和增强标准控件集。由于可以应用面向对象编程的公共原理和法则，底层的ASP.NET组件模型大大地简化了任务。

通过增强已有的控件或者将两个或多个控件组合成一个新的控件，可以构建新的控件。ASP.NET 1.x带有一个小型基类集，根据这些基类可以构建全新的控件。这个基类集在ASP.NET 2.0中得到了扩展，具体说来是简化了新的数据绑定控件的开发。

3. 自适应显示

从ASP.NET 2.0版本开始，ASP.NET采用了一个新的控件适配器构架，允许任何服务器控件创建适合各种浏览器的替代图形。但是注意，新的ASP.NET 2.0适配器模型不适用于移动控件。移动控件是一个特殊的Web控件系列，旨在构建移动设备上的应用。ASP.NET 2.0移动控件仍然使用原来的适配器模型，这个适配器模型自ASP.NET 1.1以来就有了，它适用于从MobileControl继承的控件，并且这些控件驻留在从MobilePage继承的页上。总之，如果需要用ASP.NET 2.0编写一个移动应用，应当使用移动控件，正如用ASP.NET 1.1开发移动应用一样。

1.3.2  页面框架

任何一个ASP.NET页面都是从Page类派生的类的实例。Page类是处理任何HTTP请求的模块管道的终点。作用于原始请求的各系统组件逐步建立找到页面对象所需的全部信息，以生成该标记。页面对象模型具有若干特征和功能，它们可以根据事件、脚本化(scripting)、个性化(personalization)、样式化(styling)和原型化(prototyping)进行组合。

1. 页事件

在ASP.NET运行库中，页的生命期通过一系列事件来标记。通过编写这些事件的代码，开发者可以动态地修改页输出和组成控件的状态。在ASP.NET 1.x中，页发出Init、Load、PreRender和Unload等事件，强调了该页的生命期中的关键时刻。ASP.NET 2.0增加不少新事件，允许我们更加严密而准确地遵循请求处理。具体说来，我们可以找到表示初始化阶段和装载阶段的开始和结束的新事件。第3章将全面分析页的生命期。

2. 页脚本化

页脚本对象模型允许开发者管理将被插入客户页中的脚本代码和隐藏字段。该对象模型生成JavaScript代码，用来把服务器控件生成的HTML元素粘合在一起，从而提供了服务器上的程序原本不可能有的特征。例如，应用这种方法，在客户浏览器显示该页时，就可以将输入焦点设置在一个特定控件上。

ASP.NET页经过设计，使客户可以向服务器方法发出调用，而不必执行完整的回送以及随后对整个已显示的页进行刷新。这种远程脚本引擎是通过一种回调机制实现的，这种回调机制向开发者提供了一种绝对优势。使用脚本回调机制时，服务器端方法的执行结果直接传递给一个JavaScript函数，然后该函数通过动态HTML更新用户界面。虽然往返现象仍然会发生，但是不用刷新整个页。

但是，除了脚本回调，还有另一个特征，即跨页投递(cross-page posting)，也是ASP.NET开发者社区广泛需要的。它允许把一个窗体的内容投递到另一个页上。这听起来不是有点像教老狗学新把戏吗？也算是吧。如本章前面所述，ASP.NET最有特色的一点是每页只包含一个<form>标签，它不断地向自己投递内容。这就是ASP.NET的设计方式，很多优势由此而来。

在ASP.NET的前几个版本中，跨页投递可以用与经典ASP相同的方法实现——即，通过一个没有标记runat属性的纯HTML<form>投递内容。这种方法效果不错，但是远离ASP.NET的面向对象和强类型的世界。ASP.NET 2.0版中实现的跨页投递填补了这个空缺。

3. 页个性化

在ASP.NET 2.0中，我们可以存储和检索特定用户的信息和优先权，而不必编写基础代码。应用程序本身定义个性化数据的模型，ASP.NET运行库完成其余工作，解析该模型并把它编译成一个类。个性化数据类的每个成员对应于当前用户特有的一则信息。个性化数据的装载和保存对最终用户是完全透明的，甚至不要求页面作者知道很多有关内部管道系统的信息。用户的个性化信息通过一个页属性提供给页面作者。每页可使用以前保存的信息，并保存新信息供未来的请求使用。

4. 页样式化

与Microsoft Windows XP主题很像，ASP.NET分配一组样式和可视化属性给站点的元素，使站点可定制。这些元素包括控件属性、页样式表、图像和页上的模板。一个主题是页中的所有可定制元素的所有图像式样的共同体——一种超级CSS(cascading style sheet，级联样式表)文件。主题通过名称加以标识，它由CSS文件、图像和Control Skin组成。Control Skin是一个文本文件，包含默认的控件声明，其中设置了该控件的可视特性。有了这种功能，如果开发者把一个DataGrid控件添加到一个页中，该控件就显示主题中定义的默认   外观。

主题是一个非常新的特征，因为它们允许我们在弹指之间改变页的外观和感觉，也许更重要的是，它为所有页提供了一致的外观。

5. 页原型化

今天，所有Web站点几乎都包含具有类似布局的页。对一些站点而言，布局像标题和页脚一样简单；而且其他站点可能包含复杂的导航菜单和封装内容的窗口小部件。在ASP.NET 1.x中，推荐开发者使用的方法是把这些UI块封装在用户控件中，然后在每个内容页中引用它们。可想而知，该模型在站点只包含少数页的情况下工作得非常好；不幸的是，如果站点有几百个页，则会变得难以管理。对于内容丰富的站点，基于用户控件的方法提出了若干关键问题。首先，内容页中有引用用户控件的重复代码。其次，新模板的应用要求开发者处理每一页。最后，那些跨内容区域的HTML元素，可能被分割在用户控件之间。

在ASP.NET 2.0中，由于母版页(master page)，页的原型化技术得到了极大的增强。一些网站上的很多页共享相同的布局和功能，这些网站的开发者现在可以用一个主控文件创造任何共享的功能，而不必给每个页添加布局信息，或者在几个用户控件之间分开布局。根据该共享的母版文件，只要通过一个新的属性引用该母版页，开发者就可以创建任意多个外观类似的内容页。

1.3.3  HTTP运行时环境

一个Web请求变成适合于浏览器的纯HTML文本的过程，在ASP.NET 2.0中与ASP.NET 1.1中并没有多大的不同。请求由IIS提取，并被给予一个身份标记(identity token)，然后把该请求传递给ASP.NET ISAPI扩展库(aspnet_isapi.dll)——任何ASP.NET相关处理的入口点。这是一般过程，但是许多重要的细节取决于IIS的基本版本和正在使用的过程模型。

过程模型是处理一个请求所需的操作序列。当ASP.NET运行库在IIS 5.x上运行时，该过程模型基于一个称为aspnet_wp.exe的独立的工作进程。这个Microsoft Win32进程通过托管的ASP.NET ISAPI扩展，从IIS直接接收控件。对ASP.NET资源的任何请求都传递给该扩展，而该扩展又把它们转交给工作进程。工作进程装入公共语言运行库(common language runtime，简称CLR)，并开始用管道输送管理的对象，把原始请求从一个HTTP有效负荷转换为浏览器上的一个特征全面的页。aspnet_isapi模块和工作进程实现了高级特征，诸如进程回收(process recycling)、页输出缓存、内存监督和线程池(thread pooling)。每个Web应用都在工作进程的一个独立的AppDomain中运行。在默认情况下，工作进程在一个受限制的、没有特权的ASPNET帐号下运行。

  注意 

在CLR中，应用领域(AppDomain)为运行托管代码(managed code)提供了隔离、卸载和安全边界。AppDomain是一种轻型的、CLR特有的进程，其中装载了多个程序集，并且可以保证安全地执行代码。一个CPU进程中可以运行多个AppDomain。AppDomain和线程之间没有一对一关系。几个线程可以属于一个单独的AppDomain，而一个给定的线程也不会只限于一个单独的应用领域；在任一给定时刻，一个线程在一个单独的AppDomain中运行。

当ASP.NET在IIS 6.0上运行时，默认的进程模型是不同的，并且不用aspnet_wp.exe进程。这时使用的工作进程是标准的IIS 6.0工作进程(w3wp.exe)。它查找该请求的URL，并装载一个具体的ISAPI扩展。例如，对于ASP.NET相关的请求，它就装载aspnet_isapi.dll。在IIS 6.0进程模型下，aspnet_isapi扩展负责装载CLR和启动HTTP管道。

请求进入ASP.NET HTTP管道以后，经过对其进行操作的各系统和用户定义的组件，直到找到一个有效的页类，并成功地实例化它。在一定程度上，开发者可以修改和调整运行时环境。具体有三种方式：修改已安装的HTTP模块的列表、修改配置文件、修改状态和个性化提供程序以及其他应用服务。

1. 系统HTTP模块

HTTP模块是ASP.NET中与ISAPI筛选器相对应的部分。一个HTTP模块是一个.NET Framework类，实现了一个特定的接口。所有的ASP.NET应用都继承machine.config文件中定义的几个系统HTTP模块。这些预安装的模块提供了诸如身份验证、授权和与会话相关的服务等功能。一般而言，HTTP模块可以对一个请求进行预处理和后处理，并且可以拦截和处理系统事件以及其他模块发出的事件。

幸运的是，我们可以编写和注册自己的HTTP模块，把它们插入ASP.NET运行时管道中，使它们处理系统事件，并发出它们自己的事件。另外，我们可以在每个应用的基础上调整默认HTTP模块的列表。我们可以加入定制模块，去除不需要的模块。

2. 应用配置

ASP.NET应用的行为受许多不同的参数支配；一些是系统级设置，一些则依赖于应用的特征。machine.config文件定义了公共的系统参数集。该文件包含所有支持的设置的默认值和特定机器的值。机器设置一般由系统管理员控制，应用程序不应当被授予对machine.config文件的写访问。machine.config文件位于应用程序的Web空间之外，因此，即使攻击者成功地将恶意代码注入系统中，也不可能接触到该文件。

通过创建一个或多个应用特有的web.config文件，任何应用程序都可以覆盖machine.config文件中存储的默认值。一个应用程序至少可以在它的根文件夹中创建一个web.config文件。web.config文件是machine.config的子集，也是用XML模式编写的。web.config的目标是覆盖其中一些默认设置。不过要注意，并不是说machine.config中定义的所有设置都可以在子配置文件中被覆盖。特别是有关ASP.NET进程模型的信息，只能用machine.config文件进行机器范围内的定义。

如果应用程序包含子目录，则可以为每个文件夹定义一个web.config文件。每个配置文件的作用范围以一种层次型的、自顶向下的方式进行确定。对一个页有效的设置是由修改总和决定的，即沿着应用于原始机器配置的路径发现的各web.config文件对设置做出的修改总和。任何一个web.config文件都可以扩展、限制和覆盖上一个层级(包括机器级)定义的任何设置类型。如果应用程序文件夹中没有配置文件，则应用上一个层级的有效设置。

3. 应用服务

身份验证、状态管理和缓存都是ASP.NET运行时环境向正在运行的应用提供的基本服务的实例。在ASP.NET 2.0中，该列表中增加了其他服务——包括行政管理(administration)、成员资格(membership)、角色管理(role management)和个性化(personalization)，如图1.5    所示。

 

从用户接口到系统服务                                  

大多数应用服务必须持久保存和检索一些数据供内部使用。在这个过程中，一个服务选择数据模型和存储介质，并通过特定的步骤序列得到数据。根据设计，基于这些服务的应用限于使用那些设置——通常包括一个固定的数据模式、一种预定义的存储介质、一种硬编码的行为。如果不喜欢这些限制，或者不需要这些限制，那该怎么办呢？

运行时配置(通过machine.config和web.config文件实现)增加了代码的灵活性。然而，运行时配置没有提供一个确定的、足够灵活的解决方案，允许对服务进行全面定制，使它可扩展而且容易实现。ASP.NET 2.0提供了一种比较确定的解决方案，它对一个设计模式进行了形式化处理，然后把它集成到总的类框架中。这个设计模式最初是在若干ASP.NET Starter Kit中开发和使用的，称为提供程序模型(provider model)。该模式为各种操作定义了一个公共的API——每个操作称为提供程序(provider)。同时，提供程序的接口包含几个hook(挂钩)，使开发者完全控制API的内部行为、采用的数据模式和存储介质。

重要提示 

提供程序模型是ASP.NET最重要的特征之一，对它的充分理解是执行有效的设计和实现前沿应用的关键。提供程序模型在ASP.NET 2.0中进行了形式化处理，但它只是一个设计模式的实现。因而，它的核心与任何平台和框架完全分离。因此，只要理解了这一基本思想，就可以在任何应用中使用它，甚至可以越出ASP.NET的边界。