WebForm通过一个在我们前面讲过的ASP.NET框架之上的更加高级的接口实现了HttpHandler, 但是WebForm的Render()方法简单的使用HtmlTextWriter对象去写入它最后最后的输出到Context.Response.OutputStream. 所以尽管是非常时髦的, 甚至是终极如WebForm这样的工具, 也只不过是在Request和Response对象上的高水平的抽象罢了.
你也许想知道你是否需要跟HttpHandlers打交道. 毕竟WebForms已经提供了一种容易地访问HttpHandler的实现, 所以说为什么还要费劲巴力地要去用那么低水平的对象, 和那般的灵活性呢.
WebForm对于生成复杂HTML页面很在行, 对于需要图形布局工具的, 商业级逻辑的, 基于模板的页面也是一样. 但是WebForms引擎处理的很多很多任务有点过于密集了, 没有必要. 如果你想做的一切仅仅是读取系统中的文件并通过代码将它返回的话, 那么绕过WebForms 页面处理引擎, 简简单单的将文件填入response无疑是更为高效的. 如果你做类似于从数据库读取并提供图片这样的动作, 就没必要进入到页面处理的框架里了-- 你不需要模板, 并且对于提供图片来说肯定也没有需要你用来捕捉事件的web UI了.
没必要建立起页面对象和勾住页面等级的事件- 所有的哪些需要的都是跟你眼前工作无关的代码执行.
所以handlers更高效. Handler也能做WebForms不可能做到的事, 比如不需要磁盘上的物理文件就能处理请求, 也就是我们知道的虚拟url.
这对于内容提供者来说是很常见的(content provider), 比如说动态图片处理, XML 服务器, 提供虚拟URL的URL重定向, 下载管理器等等, 这些东西都不会从WebForm引擎中占到什么便宜. (SharePoint也是这种, 因为内容都存在数据库中)
总复习
==========
我们已经完整的过了一遍对于请求处理的全过程. 关于Http Modules还有Http Handlers的工作细节, 还有很多底层的信息和细节我们没有谈到. 光说清楚这些就已经花了不少时间了, 我希望你像我一样拥有, 对这些信息在理解ASP.NET在底层如何工作上带给我的满意.
在我们结束之前, 让我们一起来快速的复习一下我们讨论过的, 从IIS到handler的过程中, 发生的事件的序列:
- IIS 得到请求
- IIS查找应用程序扩展, 并映射到aspnet_isapi.dll
- 代码调用触及了工作者进程(w3wp.exe in IIS6)
- .NET runtime 被加载.
- 非托管代码调用 IsapiRuntime.ProcessRequest()
- 对每一个request创建一个IsapiWorkerRequest
- Worker Request 作为参数, HttpRuntime.ProcessRequest()被调用
- HttpContext 对象被创建出来, 创建的方式是把Worker Request对象作为输入的参数.
- HttpApplication.GetApplicationInstance() 被调用来从池中获取实例, Context是参数
- HttpApplication.Init() 被调用来启动pipeline的事件序列, 并关联起modules和handlers
- HttpApplicaton.ProcessRequest 被调用来启动处理过程
- Pipeline 的事件们依次被触发
- Handlers 被调用, ProcessRequest方法被触发
- 控制回到pipeline, 后请求处理事件被触发
使用这个简单的列表, 我们就把讨论的所有部分放在了一起, 比较容易地记住了他们. 我是一遍又一遍的看才记住的. 所以现在, 回去干活儿, 做些不那么抽象的,实实在在的工作吧.
尽管这里的讨论是基于ASP.NET 1.1的, 看起来底层的处理跟ASP.NET 2.0并没有太大的出入.
原文地址http://www.west-wind.com/presentations/howaspnetworks/howaspnetworks.asp