是否想学习HTTP处理程序编程呢?好吧,第一步工作是熟悉IHttpHandler接口。HTTP处理程序只不过是实现该接口的托管类。更确切地 讲,同步HTTP处理程序实现IHttpHandler接口;而异步HTTP处理程序实现IHttpAsyncHandler接口。让我们先看看同步处理 程序。
IHttpHandler接口的合同定义了HTTP处理程序以同步方式处理一个HTTP请求需要采取的行动。
1. IHttpHandler接口的成员
IHttpHandler接口只定义了两个成员:ProcessRequest和IsReusable,如表2.1所示。ProcessRequest是一个方法,而IsReusable是一个布尔逻辑属性。
表2.1 IHttpHandler接口的成员
成 员 | 描 述 |
IsReusable | 该属性获得一个布尔值,指示另一个请求是否可以使用该HTTP处理程序的实例 |
ProcessRequest | 该方法处理HTTP请求 |
Page类上的IsReusable属性返回false,表示需要该HTTP请求的新实例来服务一个页面请求。通常我们使它在所有情况下都返回 false,并根据请求负荷的不同而要求它做一些有意义的处理。那些被用作筛选特殊请求的简单屏障的处理程序可以将IsReusable设置为true, 以节省一些CPU周期。稍后我将用一个具体的实例来说明这一点。
ProcessRequest方法具有如下签名:
void ProcessRequest(HttpContext context);
它以请求的上下文作为输入,并确保该请求得到服务。在同步处理程序的情况下,当ProcessRequest返回时,准备把输出发到客户端。
2. 一个简单的HTTP处理程序
再次强调,HTTP处理程序只是一个实现了IHttpHandler接口的类。请求的输出是在ProcessRequest方法中建立的,如下面的代码所示:
using System.Web;
namespace ProAspNet20.Advanced.CS.Components
{
public class SimpleHandler : IHttpHandler
{
// Override the ProcessRequest method
public void ProcessRequest(HttpContext context)
{
context.Response.Write("<H1>Hello, I'm an HTTP handler</H1>");
}
// Override the IsReusable property
public bool IsReusable
{
get { return true; }
}
}
}
我们需要一个能够调用该处理程序的入口点。在此上下文中,该处理程序代码的入口点只不过是一个HTTP终点——即,一个公共的URL。该URL必须 有一个惟一的名称,使IIS和ASP.NET运行库能够把它映射到该代码。注册时,HTTP处理程序和Web服务器资源之间的映射是通过 web.config文件建立的。
<configuration>
<system.web>
<httpHandlers>
<add verb="*" path="myHandler.aspx"
type="ProAspNet20.Advanced.CS.Components.SimpleHandler" />
</httpHandlers>
</system.web>
</configuration>
<httpHandlers>节列出了当前应用程序可用的处理程序。这些设置指示,对myHandler.aspx终点的任何输入请 求,由SimpleHandler处理程序负责处理。要注意的是,myHandler.aspx URL不必是服务器上的物理资源;它只是一个公共资源标识符。type属性引用包含该处理程序的类和程序集,它的标准格式是type[, assemly]。如果该组件在App_Code或其他保留文件夹中定义,则忽略该程序集信息。
注意 如果在machine.config文件中输入上述设置,则将把SimpleHandler组件注册成可以从服务器机器上托管的所有Web应用程序内可调用的组件。
如果调用myHandler.aspx URL,将得到如图2.2所示的结果。
图2.2 一个响应myHandler.aspx请求的HTTP处理程序示例
这里所述的方法是使用HTTP处理程序最快、最简单的方法,但是有关HTTP处理程序注册的知识,我们还有很多要了解并且还有很多其他选项可以利用。现在,让我们考虑一个更复杂的HTTP处理程序示例。
HTTP处理程序与ASP.NET页面
我们应当利用HTTP处理程序资源来实现应用程序特有的功能,它们需要比常规的Web页面被更快地处理。在任何情况下, HTTP处理程序返回一个带有内容类型和主体的有效的HTTP响应。服务一个.ashx请求,或者一个自定义处理程序托管的任何其他请求,可能会导致比服 务一个.aspx资源更快的代码。ASP.NET处理一个自定义的处理程序通常更快,因为这不必对用户代码引发任何中间事件(例如,Init, Load),不必托管任何视图状态,而且也不支持任何回发机制。大概说来,对一个自定义的HTTP处理程序的请求类似于对.aspx资源的请求,其中只发 生呈现步骤。此外,找到服务一个页面请求所需的正确的HTTP处理程序可能需要更长的时间,因为这要牵涉到一个页面处理程序工厂的中间对象。
这就是说,我们要记住,ASP.NET页面只是一个HTTP处理程序——虽然是一个非常复杂而高级的HTTP处理程序。底层 的处理机制完全相同。如果说满足某种特定需要的自定义的HTTP处理程序通常比页面更快,这是因为它们通常是为了直接得到给定结果而实现的。例如,假设我 们需要显示从一个数据库中取出来的一个图像——这是我们将在第9章中详细讨论的一个主题,我们仍然需要将一个Image控件绑定到一个服务合适的MIME 类型的URL。该URL应当是一个页面吗?它当然可以是页面;但是,如果使用一个自定义的HTTP处理程序,通常会处理得更快。
ASP.NET页面是一个复杂对象,并由一个自定义的而且必定是复杂的HTTP处理程序(Page类)提供服务。就服务自定义资源而言,一定要使用一个合适的处理程序,只包
含必需的智能和复杂度。为了说明这一点,假设要运行一个查询并提供一个数据库中存储的一个图像的字节,我们不需要任何视图状态和回发管理,也不需要向该应用程序激发事件。
应当使用一般的.ashx资源,还是使用一个自定义的扩展呢?这主要取决于需要实现的功能。ASHX方法是为相对简单的场景 设计的,其中几乎不需要传递什么参数(或者根本不需要参数),并使用查询字符串来引入它们。如果有一个自定义的文档要处理,并且该文档具有以非平面的或复 杂的布局进行组织的各种信息,则最好使用自定义的扩展。