阅读目录
<a href="http://www.cnblogs.com/happyday56/p/3533671.html#_labelStart">开始</a>
<a href="http://www.cnblogs.com/happyday56/p/3533671.html#_label0">理解ASP.NET管线</a>
<a href="http://www.cnblogs.com/happyday56/p/3533671.html#_label1">理解HttpApplication</a>
<a href="http://www.cnblogs.com/happyday56/p/3533671.html#_label2">理解HttpHandler</a>
<a href="http://www.cnblogs.com/happyday56/p/3533671.html#_label3">理解HttpModule</a>
<a href="http://www.cnblogs.com/happyday56/p/3533671.html#_label4">三大对象的总结</a>
<a href="http://www.cnblogs.com/happyday56/p/3533671.html#_label5">案例演示</a>
<a href="http://www.cnblogs.com/happyday56/p/3533671.html#_label6">如何选择？</a>
<a></a>
最近收到几个疑问：HttpHandler和HttpModule之间有什么差别，我到底该选择哪个？
之所以有这个疑问，是因为在这二类对象中都可以访问Request, Response对象，都能处理请求。
很庆幸那篇博客内容没有走题，今天只好再来写一篇了。
本文约定：
1. HttpHandler泛指所有实现IHttpHandler接口的类型。
2. HttpModule泛指所有实现IHttpModule接口的类型。
因此，本文将不会特别区分这些类型与接口。
HttpHandler和HttpModule，它们都与ASP.NET管线有关，所以我想理解这二类对象必须要理解ASP.NET管线的工作方式。
下图反映了ASP.NET管线的处理流程：
这是一张时序图，我们应该从二个角度来理解它：
1. 有哪些调用动作。
2. 有哪些参与者。
图片中还反映了ASP.NET的三种主要的参与者：
1. HttpModule
2. HttpHandlerFactory
3. HttpHandler
有没有有想过：这三种参与者中，每种有多少个参与对象呢？
为了清楚地回答这个问题，我准备了下面的表格：
管线参与者
每次请求中参与者数量
HttpModule
>= 0
HttpHandlerFactory
1
HttpHandler
除开HttpHandlerFactory，我们可以发现：在ASP.NET管线中，HttpHandler应该只有一个，而HttpModule是可选的。
进而，我们是不是可以这样理解：HttpHandler才是处理请求的主角（不可缺少），HttpModule是配角（可以没有）？
前面我们一直在说ASP.NET管线，那么，谁在控制管线过程？
答案是：HttpApplication对象。
1. HttpApplication细分它的处理过程，在不同阶段引发不同的事件，使得HttpModule通过订阅事件的方式加入到请求的处理过程中。
2. 在请求的处理过程中，HttpApplication对象主要扮演着控制处理流程的推进作用。
3. HttpApplication会在固定的阶段获取一个IHttpHandler实例，然后将请求的响应过程交给具体的IHttpHandler来实现。
HttpApplication如何产生，如何工作？
1. HttpApplication对象会被重用，当HttpRuntime不能从HttpApplicationFactory获取空闲的实例时，才会创建。
2. HttpRuntime会将每个请求交给一个HttpApplication对象来处理。
3. HttpApplication对象在初始化时负责加载全部的HttpModule。
4. 每个HttpApplication对象会控制属于它的管线过程（前面已解释）。
HttpApplication是个非常重要的类型，它的许多功能都属于框架的基础部分，不需要我们调用， 因此，我们平时不会用到它。
我不想让博客走题，下面来看看今天的主角吧。
前面说到HttpRuntime会将请求交给HttpApplication来处理， 此时你有没有想过这样一个问题：为什么HttpApplication不直接处理请求，而是要再交给一个HttpHandler对象来处理呢？
答案是：每个请求的内容可能并不相同，它们存在多样性，因此ASP.NET采用了抽象工厂模式来处理这些请求。 ASP.NET在web.config的架构中，允许我们指定某些请求映射到一个HttpHandlerFactory，例如：
HttpApplication是如何将请求交给HttpHandler实例来处理的呢？
为了理解这个过程，我们要来看一下IHttpHandler接口的定义：
HttpApplication在将某个请求交给HttpHandler实例来处理时，是通过接口来调用的（ProcessRequest方法）。
与HttpHandler的相关话题：
通常我去这样创建一个ashx文件（HttpHanlder）响应某种特殊的请求。
所以，我们应该这样理解HttpHanlder：一个HttpHanlder用于响应一类特定的请求。
设计HttpHanlder的目的很明确：生成响应结果。
那么，设计HttpModule又是为什么呢？
前面说过，一个HttpHanlder用于处理一类特定的请求，每个aspx, ashx都可以认为是一类请求。 有时候我们发现所有页面可能都需要某些相同的检查功能（如身份检查）， 假如只能使用HttpHanlder，那我们就要让所有页面都去调用那些相同的检查功能。 谁愿意做这些重复的事情？ 或许有些人会回答，可以自己实现一个基类，把检查功能放在基类中去调用。 然而，这种做法只能解决重复调用问题，它会让代码失去灵活性（扩展性）， 试想一下：如果需要再加入新的检查功能，或者用新的检查方法替换原有的检查逻辑时怎么办？ 只能是修改基类了吧？
设计HttpModule的目的正是为了提供一个灵活的方法解决这种功能重用问题。 它采用事件（观察者）的设计模式，将某些HttpHanlder都需要的功能抽取出来， 形成不同的观察者类型，这些观察者类型可以编译成类库形式，供多个网站项目共用。 为了让ASP.NET管线更灵活，ASP.NET允许我们在web.config中自由配置需要的HttpModule，例如：
配置只是告诉ASP.NET：这些HttpModule需要运行起来。 有没有想过这些HttpModule到底是如何进入管线运行起来的呢？ 前面我只是说了HttpModule会订阅这些事件，那么事件又是在哪里订阅的呢？ 还是来看一下IHttpModule接口的定义吧：
前面我分别介绍了HttpApplication，HttpHanlder和HttpModule，这里再把三者的关系重新梳理一遍。
在请求的处理过程中，HttpApplication对象主要扮演着控制管线处理流程的作用，它负责推进整个处理流程， 除了在不同阶段引发不同的事件外（供HttpModule使用），HttpApplication对象还会根据当前请求寻找一个合适的IHttpApplicationFactory实例， 并最终得到一个IHttpHandler的实例用于处理请求。
设计这三种类型的目的在于：
1. HttpApplication控制处理流程，在不同阶段引发不同的事件。
2. 由于请求的多样性，每个请求会由一个HttpHandler对象来处理。
3. 对于一些通用性的功能，尤其是与响应内容无关的，设计成HttpModule是最合适的。
Q：我有一些html文件，需要做身份认证检查（判断Session），我该如何实现？
Q：我需要压缩所有的ASP.NET请求的响应结果，该怎么实现？
在结束这篇博客之前，再问问各位读者：现在知道何时选择HttpHandler还是HttpModule了吗？
如果还没有看明白，那我就最后告诉你一个识别方法：
1. 如果要响应一类请求，那么就选择HttpHandler。
2. 如果要修改或者检查所有请求（总之就是不生成响应结果），那就选择HttpModule。
最后给各位留下一个题目，下面这些ASP.NET提供的功能，它们是采用了哪个方式实现的？
1. Session
2. 身份认证
3. URL授权检查
3. 通过trace.axd查看跟踪信息
4. OutputCache
5. 禁止下载config文件
6. 禁止查看下载源代码文件
注意：本文的主题是：选择HttpHandler还是HttpModule，所以请不要扯远了。
原文地址：http://www.cnblogs.com/fish-li/archive/2013/01/04/2844908.html
本文转自快乐就好博客园博客，原文链接：http://www.cnblogs.com/happyday56/p/3533671.html，如需转载请自行联系原作者