閱讀目錄
<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，如需轉載請自行聯系原作者