我認為：HttpHandler的強大離不開HttpContext，HttpHandler的重要性是因為管線會將每個請求都映射到一個HttpHandler。

　　通常，我們需要新的HttpHandler，創建一個ashx文件就可以了。但也可以創建自己的HttpHandler，或者要將一類【特殊的路徑/擴展名】交給某個處理器來處理，那么就需要我們在web.config中注冊那個處理器。

　　注意：如果是【特殊的擴展名】可能還需要在IIS中注冊，原因很簡單：IIS不將請求交給ASP.NET，我們的代碼根本沒機會運行！

　　我們可以采用以下方式在web.config中注冊一個自定義的處理器：

　　<httpHandlers>  
　　<add path="/MyService.axd" verb="*" validate="false" type="MySimpleServiceFramework.MyServiceHandler"/>  
　　</httpHandlers> 

　　或者：（為了排版，我將一些代碼做了換行處理）

　　<httpHandlers>  
　　<remove verb="*" path="*.cs"/>  
　　<add verb="*" path="*.cs" validate="false" type="FishWebLib.Ajax.AjaxMethodV2Handler,  
FishWebLib, Version=3.0.0.0, Culture=neutral, PublicKeyToken=04db02423b9ebbb2"/>　　
FishWebLib, Version=3.0.0.0, Culture=neutral, PublicKeyToken=04db02423b9ebbb2"/>  
　　<remove verb="*" path="*.ascx"/>  
　　<add verb="*" path="*.ascx" validate="false" type="FishWebLib.Ajax.UserControlHandler,  
FishWebLib, Version=3.0.0.0, Culture=neutral, PublicKeyToken=04db02423b9ebbb2"/>　　
FishWebLib, Version=3.0.0.0, Culture=neutral, PublicKeyToken=04db02423b9ebbb2"/>  
　　</httpHandlers> 

　　HttpModule

　　前面我已經提到過HttpModule的工作方式：訂閱管線事件，并在事件處理器中執行所需的相關操作。

　　這個描述看起來很平淡，但是，它的工作方式給了它無限強大的處理能力。

　　它的無限強大的處理能力來源于可以訂閱管線事件，因此，它有能力可以在許多階段修改請求，這些修改最終可能會影響請求的處理。

　　前面我說過：“HttpHandler是處理請求的主要對象”，但HttpModule卻可以隨意指定將某個請求交給某個處理器來執行！

　　甚至，HttpModule也可以直接處理請求，完全不給HttpHandler工作的機會！

　　我們來看一下HttpModule的實現方式：

　　/// <summary>  
　　/// 能支持雙向GZIP壓縮的Module，它會根據客戶端是否啟用GZIP來自動處理。  
　　/// 對于服務來說，不用關心GZIP處理，服務只要處理輸入輸出就可以了。  
　　/// </summary>  
　　internal class DuplexGzipModule : IHttpModule  
　　{  
　　public void Init(HttpApplication app)  
　　{  
　　app.BeginRequest += new EventHandler(app_BeginRequest);  
　　}  
　　void app_BeginRequest(object sender, EventArgs e)  
　　{  
　　HttpApplication app = (HttpApplication)sender;  
　　// 注意：這里不能使用"Accept-Encoding"這個頭，二者的意義完全不同。  
　　if( app.Request.Headers["Content-Encoding"] == "gzip" ) {  
　　app.Request.Filter = new GZipStream(app.Request.Filter, CompressionMode.Decompress);  
　　app.Response.Filter = new GZipStream(app.Response.Filter, CompressionMode.Compress);  
　　app.Response.AppendHeader("Content-Encoding", "gzip");  
　　}  
　　}  
　　public void Dispose()  
　　{  
　　}  
　　} 

　　每個HttpModule只需要實現IHttpModule接口就可以了。IHttpModule也是個簡單的接口：

　　public interface IHttpModule  
　　{  
　　void Dispose();  
　　void Init(HttpApplication app);  
　　} 

　　在這二個方法中，***個方法通?？梢员３譃榭铡Ｗ钪匾姆椒ň褪荌nit，它給了HttpModule能訂閱管線事件的機會，然后在相應的事件處理中，我們就可以執行它的具體操作了。

　　還記得我在博客【我心目中的ASP.NET核心對象】***給出一個示例嗎？在QueryOrderService.ashx中，為了支持gzip，需要直接調用GZipStream類，對于一二個ashx來說，或許不是問題，如果這樣的處理器變多了，每個處理器都那樣寫，您能受得了嗎？反正我是受不了的，因此今天我把它改成使用Module來實現，代碼簡單了許多。在本文末尾可以下載。

　　對于ASP.NET項目來說：當您發現有很多處理輸入輸出的操作非常類似時，那正是HttpModule可以發揮的舞臺，請把這些重復的操作交給它吧。

　　讓HttpModule工作也需要在web.config中注冊：

　　<httpModules>  
　　<add name="DuplexGzipModule" type="MySimpleServiceFramework.DuplexGzipModule"/>  
　　</httpModules> 

　　通常，我會把一些HttpModule放在類庫中實現，然后在需要使用的項目的web.config中注冊。

　　這也體現它的高重用性：寫一次，許多項目就可以直接使用。

　　HttpModule的加載方式：前面我說過“ASP.NET會為每個請求分配一個HttpApplication對象”，在每個HttpApplication對象的初始化操作中，它會加載所有在web.config中注冊的HttpModule。由于ASP.NET并不是只創建一個HttpApplication對象，而是多個HttpApplication對象，因此每個HttpModule的Init事件是有可能被多次調用的。許多人喜歡在這里做各類初始化的操作，那么請注意在這里修改靜態變量成員時的線程安全問題。特別地，如果要執行程序初始化的操作，那么還是把代碼放在Global.asax的Application_Start中去處理吧， HttpModule的Init事件并不合適。

　　為HttpModule選擇訂閱合適的管線事件：這是非常重要的，訂閱不同的事件，產生的結果也會不一樣。原因也很簡單，在ASP.NET運行環境中，并不只有一個HttpModule，某個HttpModule的判斷可能要依據其它HttpModule的輸出結果，而且在某些（晚期的）管線事件中，也不能再修改輸出數據。在后面的示例中，DirectProcessRequestMoudle訂閱了PostAuthorizeRequest事件，如果訂閱BeginRequest事件或許將得到更好的性能，但是，在BeginRequest事件中，身份認證模塊還沒有工作，因此每個請求在這個事件階段都屬于“未登錄”狀態。

　　前面說了一大堆的HttpModule，事實上，在這個示例中，主角是另一個對象：Filter 。上篇博客我就提過它，***為了演示它，把它放在一個HttpHandler里【糟蹋了】，沒辦法，上篇的主題不是管線呀。今天只好和HttpModule一起出場了。我認為Filter還是應該和HttpModule一起使用才能發揮它的獨特價值。Filter的特點還真不合適在HttpHandler中使用，如果您在HttpHandler里使用Filter，我認為有必要考慮一下是不是用錯了。

　　借HttpModule的地盤我們來談談Filter。Filter很低調，低調到什么程度：可能很少有人關注過它，因此也少有人用過它。事實也確實如此，一般情況下可以不用它，但用到它，你會發現它非常強大。前面我經常說到【輸入輸出流】，請求的數據，除了請求頭以外，基本上全放在流中，如果您希望對這些數據以流的方式進行處理，特別是希望對于所有請求，或者某類請求，那么使用Filter是非常恰當的。前面的示例就是一個非常合理地使用，好好地品味它，或許您還能發現Filter能做更多的事情。

　　選 HttpHandler 還是 HttpModule ？

　　HttpHandler是每個請求的主要處理對象，而HttpModule可以選擇請求交給哪個HttpHandler來處理，甚至，它還可以選擇它自己來處理請求。

　　下面我給個示例代碼來說明HttpModule也能直接請求：

　　/// <summary>  
　　/// 此Module示范了直接使用Module也能處理客戶端的請求。  
　　/// 建議：除非要很好的理由，否則不建議使用這種方法。  
　　/// </summary>  
　　internal class DirectProcessRequestMoudle : IHttpModule  
　　{  
　　public void Init(HttpApplication app)  
　　{  
　　app.PostAuthorizeRequest += new EventHandler(app_PostAuthorizeRequest);  
　　}  
　　void app_PostAuthorizeRequest(object sender, EventArgs e)  
　　{  
　　HttpApplication app = (HttpApplication)sender;  
　ServiceInfo info = GetServiceInfo(app.Context);  
　　if( info == null )  
　　return;  
　　ServiceExecutor.ProcessRequest(app.Context, info);  
　　app.Response.End();  
　　} 

　　為了更好的回答本節的這個問題，我再給段等效的代碼，不過，請求是經過HttpHandler來處理

　internal class MyServiceHandler : IHttpHandler  
　　{  
　internal ServiceInfo ServiceInfo { get;set;}  
　　public void ProcessRequest(HttpContext context)  
　　{  
　　ServiceInfo info = this.ServiceInfo ?? GetServiceInfo(context);  
　　ServiceExecutor.ProcessRequest(context, info);  
　　} 

　　HttpHandler和HttpModule都能處理請求，我該選哪個？？

　　對于此類情況，我的答案是：視情況而定，正如我在注釋中描述的那樣，除非要很好的理由，否則不建議使用HttpModule處理請求。用HttpModule在某些時候可能會快點，關鍵點在于處理完成時要調用Response.End();這會讓后面的事件全都短路，其它的HttpModule就沒有機會執行。如果您的框架或者項目設計很依賴于管線中的事件處理，那么調用Response.End();無疑會破壞這個規則，也將會導致不能得到正確的結果。選擇HttpHandler就不會有這種事情發生。

　　不過，也沒有絕對的事情：在請求處理期間，您可以在任何地方調用Response.End(); 結果也是一樣的。

　　幸好，短路的情況并不經常發生，因此選擇HttpHandler會讓整個ASP.NET的管線都能發揮作用，因此，我建議優先選擇HttpHandler。

　　尤其是在HttpHandler能很好的完成工作的前提下，就應該選HttpHandler，因為選HttpModule會給其它請求帶來不必要的性能損失，具體細節請繼續閱讀。

　　其實，我們還可以從另一個角度來看這個問題。

　　首先，請仔細地閱讀前面的示例代碼，您是否發現它們在實現方式上非常類似？

　　現在應該找到答案了吧：把具體的處理操作分離到HttpHandler，HttpModule之外的地方。那么，此時這個問題也就不是問題了，您也可以提供多種方案供使用者選擇。比如：我就為【我的服務框架】提供了5種方式讓使用者可以輕松地將一個C#方法公開為一個服務方法，該如何選擇這個問題，由使用者來決定，這個問題不會讓我為難。

　　我的觀點：在沒有太多技術難度的前提下，提供多種解決辦法應該是對的，您將會避開很多麻煩事情。

　　看不見的性能問題

　　前面我介紹了HttpModule的重要優點：高重用性。只要寫好一個HttpModule可以放在任何ASP.NET項目中使用，非常方便。

　　不過，再好的東西也不能濫用。HttpModule也可以對性能產生負面影響。原因也很簡單：對于每個ASP.NET請求，每個HttpModule都會在它們所訂閱的事件中，去執行一些操作邏輯。這些操作邏輯或許對一些請求是無意義的，但仍會執行。因此，計算機將會白白浪費一些資源去執行一些無意義的代碼。

　　知道了原因，解決辦法也就很清楚了：

　　1. 去掉不需要的HttpModule

　　2. 在每個HttpModule的事件處理器中，首先要確定是不是自己所需要處理的請求。對一些不相關的請求，應該立即退出。

　　在我們創建一個ASP.NET項目時，如果不做任何修改，微軟已經為我們加載了好多HttpModule 。請看以下代碼：

　　protected void Page_Load(object sender, EventArgs e)  
　　{  
　　HttpApplication app = HttpContext.Current.ApplicationInstance;  
　　StringBuilder sb = new StringBuilder();  
　　foreach( string module in app.Modules.AllKeys )  
　　sb.AppendFormat(module).Append("<br />");  
　　Response.Write(sb.ToString());  
　} 

　　輸出結果如下：

總共有14個。

　　哎，大多數是我肯定不會用到的，但它們卻被加載了，因此，在它們所訂閱的事件中，它們的代碼將會檢查所有的請求，那些無意義的代碼將有機會執行。如果您不想視而不見，那么請在web.config中做類似的修改，將不需要的Module移除。

　　<httpModules> 
　　<remove name="Session"/> 
　　<remove name="RoleManager"/> 
　　</httpModules> 

　　HttpModule的第2個需要注意的地方是：HttpModule對所有的請求有效，如果HttpModule不能處理所有的請求，那么請先判斷當前請求是否需要處理，對于不需要處理的請求，應該立即退出。請看以下示例代碼：

　　/// <summary>  
　　/// 【演示用】讓Aspx頁的請求支持gzip壓縮輸出  
　　/// </summary>  
　　public class FishGzipModule : IHttpModule  
　　{  
　　public void Init(HttpApplication app)  
　　{  
　　app.BeginRequest += new EventHandler(app_BeginRequest);  
　}  
　　void app_BeginRequest(object sender, EventArgs e)  
　　{  
　　HttpApplication app = (HttpApplication)sender;  
　　// 這里做個簡單的演示，只處理aspx頁面的輸出壓縮。  
　　// 當然了，IIS也提供壓縮功能，這里也僅當演示用，或許可適用于一些特殊場合。  
　　if( app.Request.AppRelativeCurrentExecutionFilePath.EndsWith(  
　　"aspx", StringComparison.OrdinalIgnoreCase) == false )  
　　// 注意：先判斷是不是要處理的請求，如果不是，直接退出。  
　　// 而不是：先執行了后面的判斷，再發現不是aspx時才退出。  
　　return;  
　　string flag = app.Request.Headers["Accept-Encoding"];  
　　if( string.IsNullOrEmpty(flag) == false &&flag.ToLower().IndexOf("gzip") >= 0 ) {  
　　app.Response.Filter = new GZipStream(app.Response.Filter, CompressionMode.Compress);  
　　app.Response.AppendHeader("Content-Encoding", "gzip");  
　　}  
　　} 

　　更多實戰介紹

　　本文從這里起，將不再過多的敘述一些理論文字，而是將以實戰的形式展示ASP.NET的強大管線功能，這些實戰展示了一些很經典的應用場景，其中大部分示例代碼將做為【我的服務框架】的關鍵部分。因此請注意理解這些代碼。

　　實戰代碼大量使用了上篇博客【我心目中的ASP.NET核心對象】所介紹的絕大多數對象，也算是再次展示那些核心對象的重要性，因此請務必先了解那些核心對象。

　　上篇博客僅展示了那些強大對象的功能，單獨使用它們，也是不現實的，今天，我將演示它們與HttpHandler, HttpModule一起并肩工作所能完成的各種任務。

　　故事未講完，傳奇在繼續。更多精彩即將上演！

　　實戰演示 - 模擬更多的HttpMethod

　　近幾年又有一種被稱為RESTful Web服務的概念進入開發人員的視野，它提倡使用HTTP協議提供的GET、POST、PUT和DELETE方法來操作網絡資源。不過，目前的瀏覽器只支持GET、POST這二種方法，因此就有人想到采用HTTP頭，表單值，或者查詢字符串的形式來模擬這些瀏覽器不支持的HTTP方法。每種支持RESTful Web服務的框架都有它們自己的實現方式，今天我將使用HttpModule也來模擬這個操作。最終的結果是可以直接訪問HttpRequest.HttpMethod獲取這些操作的方法名字。

　　實現原理：訂閱管線中的BeginRequest事件，檢查當前請求是否需要修改HttpMethod，如果是，則修改HttpMethod屬性。

　　所以選擇BeginRequest這個事件，是因為這個事件比較早，可以讓請求的后續階段都能讀到新的結果。

　　/// <summary>  
　　/// 【演示用】實現了模擬更多 HttpMethod 的Module  
　　/// </summary>  
　　internal class XHttpMethodModule : IHttpModule  
　　{  
　　private FieldInfo _field;  
　public void Init(HttpApplication context)  
　　{  
　　// 訂閱這個較早的事件，可以讓請求的后續階段都能讀到新的結果。  
　　context.BeginRequest += new EventHandler(context_BeginRequest);  
　　_field = typeof(HttpRequest).GetField("_httpMethod", BindingFlags.Instance | BindingFlags.NonPublic);  
　　}  
　　void context_BeginRequest(object sender, EventArgs e)  
　　{  
　　HttpApplication app = (HttpApplication)sender;  
　　// 這里僅檢查是否為POST操作，如果您的應用中需要使用GET來模擬的，請修改這里。  
　　if( string.Equals(app.Request.HttpMethod, "POST", StringComparison.OrdinalIgnoreCase) ) {  
　　// 這里為了簡單，我只檢查請求頭，如果還需要檢查表單值或者查詢字符串，請修改這里。  
　　string headerOverrideValue = app.Request.Headers["X-HTTP-Method-Override"];  
　　if( string.IsNullOrEmpty(headerOverrideValue) == false ) {  
　　if( string.Equals(headerOverrideValue, "GET", StringComparison.OrdinalIgnoreCase) == false &&  
　　string.Equals(headerOverrideValue, "POST", StringComparison.OrdinalIgnoreCase) == false ) {  
　　// HttpRequest.HttpMethod屬性其實就是訪問_httpMethod這個私有字段，我將直接修改它。  
　　// 這樣修改后，最原始的HTTP方法就丟失，通常這或許也是可以接受的。  
　　_field.SetValue(app.Request, headerOverrideValue.ToUpper());  
　　}  
　　}  
　　}  
　　} 

　　我認為采用HttpModule來處理這個問題是個不錯的選擇。它至少有2個好處：

　　1. 這個HttpModule能繼續給其它的網站項目使用，因此提高了代碼的重用性。

　　2. 我可以隨時決定要不要支持模擬，不需要模擬時，從web.config中不加載它就可以了，因此切換很靈活，且不需要修改現有代碼。

　　來看一下頁面及調用結果吧

　　protected void Page_Load(object sender, EventArgs e)  
　　{  
　　Response.Write(Request.HttpMethod);  
　　} 

調用結果如下：

實戰演示 - URL重寫

　　使用HttpModule來實現URL重寫。這個功能應該是HttpModule非常經典的應用了。

　　通常情況下，這種應用常用的方式是將一個URL： /product/12 重寫為 /product.aspx?id=12 ，此時product.aspx應該是一個已經已存在的頁面。顯然重寫后的地址更友好。URL重寫的目的就是能讓URL更友好。

　　實現原理：訂閱管線的PostAuthorizeRequest事件，檢查URL是不是期望修改的模式，如果是，則調用Context.RewritePath()完成URL的重寫操作。在管線的后續處理中，最終會使用新的URL來映射到一個合適的HttpHandler。說明：選擇的事件只要在【第10個事件】之前就可以了，因為在第10個事件前重寫URL，才能保證到將請求映射到合適的處理器來執行。就這么簡單，請參考以下代碼：

　　public class MyServiceUrlRewriteModule : IHttpModule  
　　{  
　　// 為了演示簡單，直接寫死地址。  
　// 注意：MyService.axd 必須在web.config中注冊，以保證它能成功映射。  
　　public static string RewriteUrlPattern = "/MyService.axd?sc={1}&op={1}";  
　　public void Init(HttpApplication app)  
　　{  
　　app.PostAuthorizeRequest += new EventHandler(app_PostAuthorizeRequest);  
　　}  
　　void app_PostAuthorizeRequest(object sender, EventArgs e)  
　　{  
　　HttpApplication app = (HttpApplication)sender;  
　　// 這里將檢查URL是否為需要重寫的模式，比如:  
　　// http://localhost:11647/service/OrderService/QueryOrder  
　　NamesPair pair = FrameworkRules.ParseNamesPair(app.Request);  
　　if( pair == null )  
　　return;  
　　// 開始重寫URL，***將會映射到MyServiceHandler  
　　int p = app.Request.Path.IndexOf('?');  
　　if( p >0 )  
　　app.Context.RewritePath(string.Format(RewriteUrlPattern, pair.ServiceName, pair.MethodName)  
　　+ "&" + app.Request.Path.Substring(p + 1)  
　　);  
　　else 
　　app.Context.RewritePath(string.Format(RewriteUrlPattern, pair.ServiceName, pair.MethodName));  
　　} 

　　重寫發生了什么？

　　對于一個傳入請求：http://localhost:11647/service/FormDemoService/ShowUrlInfo

　　它將被重寫為：http://localhost:11647/MyService.axd?sc=FormDemoService&op=ShowUrlInfo

　　由于在web.config中，對MyService.axd已做過注冊，因此ASP.NET會將請求轉交給注冊的處理器來處理它。

　　注意：URL重寫，會影響某些變量的值。請參考以下代碼，我將寫個服務方法來檢測這個現象：

　　[MyServiceMethod]

　　public string ShowUrlInfo(int a)

　　{

　　System.Web.HttpRequest request = System.Web.HttpContext.Current.Request;

　　System.Text.StringBuilder sb = new System.Text.StringBuilder();

　　sb.AppendFormat("Path: {0} ", request.Path);

　　sb.AppendFormat("RawUrl: {0} ", request.RawUrl);

　　sb.AppendFormat("Url.PathAndQuery: {0} ", request.Url.PathAndQuery);

　　return sb.ToString();

　　}

　　輸出結果：

實戰演示 - URL路由

　　使用HttpModule來實現URL路由。這個功能隨著ASP.NET MVC框架的出現也逐漸流行起來了。

　　URL路由的目標也是為了使用URL更友好，與URL重寫類似。

　　實現原理：訂閱管線的PostResolveRequestCache事件，檢查URL是不是期望的路由模式，如果是，則要根據請求中所包含的信息找到一個合適的處理器，并臨時保存這個處理器，重寫URL到一個ASP.NET能映射處理器的地址。在管線的PostMapRequestHandler中，檢查前面有沒有臨時保存的處理器，如果有，則重新給Context.Handler賦值，并重寫URL到原始地址。在管線的后續處理中，最終會使用Context.Handler的HttpHandler。就這么簡單，請參考以下代碼：

　　public class MyServiceUrlRoutingModule : IHttpModule

　　{

　　private static readonly object s_dataKey = new object();

　　public void Init(HttpApplication app)

　　{

　　app.PostResolveRequestCache += new EventHandler(app_PostResolveRequestCache);

　　app.PostMapRequestHandler += new EventHandler(app_PostMapRequestHandler);

　　}

　　private void app_PostResolveRequestCache(object sender, EventArgs e)

　　{

　　HttpApplication app = (HttpApplication)sender;

　　// 獲取合適的處理器，注意這是與URL重寫的根本差別。

　　// 即：根據當前請求【主動】尋找一個處理器，而不是使用RewritePath讓ASP.NET替我們去找。

　　MyServiceHandler handler = GetHandler(app.Context);

　　if( handler == null )

　　return;

　　// 臨時保存前面獲取到的處理器，這個值將在PostMapRequestHandler事件中再取出來。

　　app.Context.Items[s_dataKey] = handler;

　　// 進入正常的MapRequestHandler事件，隨便映射到一個處理器就行了。

　　app.Context.RewritePath("~/MyServiceUrlRoutingModule.axd");

　　}

　　private void app_PostMapRequestHandler(object sender, EventArgs e)

　　{

　　HttpApplication app = (HttpApplication)sender;

　　// 取出在PostResolveRequestCache事件中獲得的處理器

　　MyServiceHandler handler = (MyServiceHandler)app.Context.Items[s_dataKey];

　　if( handler != null ) {

　　// 還原URL請求地址。注意這里和URL重寫的差別。

　　app.Context.RewritePath(app.Request.RawUrl);

　　// 還原根據GetHandler(app.Context)調用得到的處理器。

　　// 因為此時app.Context.Handler是由"~/MyServiceUrlRoutingModule.axd"映射得到的。

　　app.Context.Handler = handler;

　　}

　　}

　　注意：在MyServiceUrlRoutingModule中，我將請求【路由】到一個MyServiceHandler的實例，而不是讓ASP.NET根據URL來替我選擇。

　　在URL重寫的演示中，有些URL相關的屬性發生了改變，我們再來看一下URL路由是個什么結果：

實現自己的服務框架

　　本篇博客在開頭說過：將在本次博客中改進上次的服務實現，讓它成為一個真正能用的服務框架。

　　前面在講述ASP.NET管線時，給出了很多示例代碼，這些示例代碼都可以在博客的結尾處下載到。這些代碼來源于【我的服務框架】中的部分源代碼，下面我將重點介紹【我的服務框架】。

　　利用【我的服務框架】將類公開成服務

　　在【我的服務框架】中，一個類要想公開為服務類，并不需要繼承某個類或者實現什么接口，只需要在類上加一個特性就好了，方法也只需加一個特性，示例代碼如下：

　　[MyService]

　　public class OrderService

　　{

　　[MyServiceMethod]

　　public static string Hello(string name)

　　{

　　return "Hello " + name;

　　}

　　[MyServiceMethod]

　　public List<Order>QueryOrder(QueryOrderCondition query)

　　{

　　// 模擬查詢過程，這里就直接返回一個列表。

　　List<Order>list = new List<Order>();

　　for( int i = 0;i <10;i++ )

　　list.Add(DataFactory.CreateRandomOrder());

　　return list;

　　}

　　public string HiddenMethod(string aa)

　　{

　　// 這個方法應該是不能以服務方式被調用到的。

　　throw new NotImplementedException();

　　}

　　}

　　如果某個方法需要只公開給登錄用戶或者指定的用戶，還可以使用以下方式：

　　// 這是一個訪問受限的服務類，只允許某些用戶調用。

　　[Authorize]

　　[MyService]

　　public static class LimitService

　　{

　　[Authorize(Users="fish-li, cc")]

　　[MyServiceMethod]

　　public static string CalcPassword(string pwd)

　　{

　　// 這個方法只能由 fish-li, cc 二個用戶來調用

　　if( pwd == null )

　　pwd = string.Empty;

　　byte[] buffer = (new MD5CryptoServiceProvider()).ComputeHash(Encoding.Default.GetBytes(pwd));

　　return BitConverter.ToString(buffer).Replace("-", "");

　　}

　　[MyServiceMethod]

　　public static string CalcBase64(string str)

　　{

　　// 這個方法只能由已登錄用戶調用。

　　if( string.IsNullOrEmpty(str) )

　　return string.Empty;

　　return Convert.ToBase64String(Encoding.UTF8.GetBytes(str));

　　}

　　}

　　就這么簡單，一個類，就可以成為一個服務。

　　說明：本框架并不要求將服務類在網站項目中實現，完全可以放在類庫中實現。

　　還可以支持Session哦。

　　[MyService(SessionMode=SessionMode.Support)]

　　public class SessionDemoService

　　{

　　[MyServiceMethod]

　　public int Add(int a)

　　{

　　// 一個累加的方法，檢驗是否可以訪問Session

　　if( System.Web.HttpContext.Current.Session == null )

　　throw new InvalidOperationException("Session沒有開啟。");

　　object obj = System.Web.HttpContext.Current.Session["counter"];

　　int counter = (obj == null ? 0 : (int)obj);

　　counter += a;

　　System.Web.HttpContext.Current.Session["counter"] = counter;

　　return counter;

　　}

　　}

　　SessionMode的定義如下：

　　public enum SessionMode

　　{

　　NotSupport,

　　Support,

　　ReadOnly

　　}

　　【我的服務框架】支持的序列化的種類

　　在上篇博客中，我演示了使用JSON序列化的做法來實現一個服務響應。本來也是打算讓框架僅支持JSON序列化的，因為傳輸的數據量小嘛。沒想到，做到后來，還是認為有必要把XML序列化也加進來，XML序列化快呀。***，居然想到既然是服務框架，Ajax調用也能算是服務吧，總不能不支持吧，后來干脆也能支持部分的Ajax調用了。

　　在【我的服務框架】中，服務端判斷客戶端發送的數據序列化方式是通過判斷請求頭"Serializer-Format"來實現的。序列化的種類還允許繼續自定義。只要實現以下接口：

　　public interface ISerializerProvider

　　{

　　object Deserialize(Type destType, HttpRequest request);

　　void Serializer(object obj, HttpResponse response);

　　}

　　然后調用以下方法就可以了：

　　public static class SerializerProviderFactory

　　{

　　public static void RegisterSerializerProvider(string name, Type type)

　　{

　　// ...................................

　　}

　　判斷客戶端的序列化方式，由屬性FrameworkRules.GetSerializerFormat來決定：

　　public static class FrameworkRules

　　{

　　private static string Internal_GetSerializerFormat(HttpRequest request){

　　string flag = request.Headers["Serializer-Format"];

　　return (string.IsNullOrEmpty(flag) ? "form" : flag);

　　}

　　private static Func<HttpRequest, string>_serializerFormatRule = Internal_GetSerializerFormat;

　　/// <summary>

　　/// 此委托用來判斷客戶端發起的請求中，數據是以什么方式序列化的。

　　/// 返回的結果將會交給SerializerProviderFactory.GetSerializerProvider()來獲取序列化提供者

　　/// 默認的實現是檢查請求頭："Serializer-Format"

　　/// </summary>

　　public static Func<HttpRequest, string>GetSerializerFormat

　　{

　　internal get { return _serializerFormatRule; }

　　set

　　{

　　if( value == null )

　　throw new ArgumentNullException("value");

　　_serializerFormatRule = value;

　　}

　　}

　　只是一個委托，可以自己重新實現。

　　目前本框架提供了三個實現了接口ISerializerProvider的類供用戶使用：JsonSerializerProvider, XmlSerializerProvider, FormSerializerProvider

　　這里只展示JsonSerializerProvider的實現：

　　internal class JsonSerializerProvider : ISerializerProvider

　　{

　　private static readonly MethodInfo s_JSSDeserializeMI

　　= typeof(JavaScriptSerializer).GetMethod("Deserialize");

　　JavaScriptSerializer jss = new JavaScriptSerializer();

　　public object Deserialize(Type destType, HttpRequest request)

　　{

　　StreamReader sr = new StreamReader(request.InputStream, request.ContentEncoding);

　　string input = sr.ReadToEnd();

　　MethodInfo deserialize = s_JSSDeserializeMI.MakeGenericMethod(destType);

　　return deserialize.Invoke(jss, new object[] { input });

　　}

　　public void Serializer(object obj, HttpResponse response)

　　{

　　if( obj == null )

　　return;

　　response.ContentType = "application/json";

　　response.Write(jss.Serialize(obj));

　　}

　　注意：FormSerializerProvider的實現不夠完善，因為再搞下去，就和【我的WEB框架】就重復了。有興趣的自己去完善吧。

　　這里再給自己的作品打個廣告：

　　【ASP.NET MVC 框架，我也來山寨一下】， 【曬曬我的Ajax服務端框架】， 【我的Ajax服務端框架 - (1) JS直接調用C#方法】

　　【我的服務框架】對gzip的支持

　　對于gzip的支持，我只想說：太簡單了。

　　前面不是已給出DuplexGzipModule的實現代碼嘛。是的，就是把它注冊到web.config中就可以了。

　　你說簡不簡單？ 完全不用寫多余的代碼，要不要gzip支持，也只是個配置問題！

　　說到這里，我想起前段時間Artech寫的一篇博客通過WCF擴展實現消息壓縮，正如我在前篇博客的回復中說到的：“本來真沒興趣看的，不過，為了驗證我的猜想，還是去看了一下，果然也沒讓我失望。”。

　　在此，有必要公開一下我的想法：絕對沒有半點看不起Artech的意思，只是我對WCF沒有興趣了。理由也簡單：不夠簡單。

　　還是接著說，Artech的博客展示了在WCF中壓縮消息的方式，當然我相信Artech對于WCF的理解，他的方案或許應該是最簡單的解決方案，但是和【我的服務框架】對gzip的支持的易用性根本沒法比。

　　WCF的粉絲們，當您看到這里，請先別忙著噴我。聽我說完：WCF的確很強大，我的這個不到700行的框架那也是根本不能和它相比的。

　　做這個比較僅僅是為了展示ASP.NET是一個強大的平臺，ASP.NET有更高水準的擴展性。

　　利用【我的服務框架】發布服務的5種方式

　　【我的服務框架】可以提供5種不同的方式，讓您將一個類及方法公開成一個服務，供外界調用。

　　方法1：使用DirectProcessRequestMoudle，只需要配置web.config即可。

　　<httpModules>

　　<add name="DirectProcessRequestMoudle" type="MySimpleServiceFramework.DirectProcessRequestMoudle"/>

　　</httpModules>

　　客戶端調用URL：http://localhost:11647/service/OrderService/QueryOrder

　　說明：URL模式是可以自由定義的，只要給FrameworkRules.ParseNamesPair賦值即可，它的定義如下：

　　public static Func<HttpRequest, NamesPair>ParseNamesPair

　　默認的實現方式：

　　internal static class UrlPatternHelper

　　{

　　// 為了演示簡單，我只定義一個URL模式。【因為我認為對于服務來說，一個就夠了】

　　// 如果希望適用性更廣，可以從配置文件中讀取，并且可支持多組URL模式。

　　// URL中加了"/service/"只是為了能更好地區分其它請求，如果您的網站沒有子目錄，刪除它也是可以的。

　　private static readonly string UrlPattern = @"/service/(?<name>[^/]+)/(?<method>[^/]+)[/?]?";

　　public static NamesPair ParseNamesPair(HttpRequest request)

　　{

　　if( request == null )

　　throw new ArgumentNullException("request");

　　MatchCollection matchs = Regex.Matches(request.Path, UrlPattern);

　　if( matchs.Count != 1 )

　　return null;

　　Match m = matchs[0];

　　return new NamesPair {

　　ServiceName = m.Result("${name}"),

　　MethodName = m.Result("${method}")

　　};

　　}

　　客戶端調用URL： http://localhost:11647/service/OrderService/QueryOrder

　　方法2：使用MyServiceUrlRoutingModule，只需要配置web.config即可。

　　<httpModules>

　　<add name="MyServiceUrlRoutingModule" type="MySimpleServiceFramework.MyServiceUrlRoutingModule"/>

　　</httpModules>

　　客戶端調用URL： http://localhost:11647/service/OrderService/QueryOrder

　　說明：只有這種方式才能支持Session

　　方法3：使用MyServiceUrlRewriteModule，只需要配置web.config即可。

　　<httpHandlers>

　　<add path="/MyService.axd" verb="*" validate="false" type="MySimpleServiceFramework.MyServiceHandler"/>

　　</httpHandlers>

　　<httpModules>

　　<add name="MyServiceUrlRewriteModule" type="MySimpleServiceFramework.MyServiceUrlRewriteModule"/>

　　</httpModules>

　　客戶端調用URL： http://localhost:11647/service/OrderService/QueryOrder

　　方法4：使用MyServiceHandler，只需要配置web.config即可。

　　<httpHandlers>

　　<add path="/MyService.axd" verb="*" validate="false" type="MySimpleServiceFramework.MyServiceHandler"/>

　　</httpHandlers>

　　客戶端調用URL： http://localhost:11647/MyService.axd?sc=OrderService&op=QueryOrder

　　方法5：創建一個ashx，不需要任何配置。

　　<%@ WebHandler Language="C#" Class="MyService" %>

　　using System;

　　using System.Web;

　　using MySimpleServiceFramework;

　　public class MyService : IHttpHandler {

　　public void ProcessRequest (HttpContext context) {

　　NamesPair pair = new NamesPair();

　　pair.ServiceName = context.Request.QueryString["sc"];

　　pair.MethodName = context.Request.QueryString["op"];

　　ServiceExecutor.ProcessRequest(context, pair);

　　}

　　public bool IsReusable {

　　get {

　　return false;

　　}

　　}

　　}

　　客戶端調用URL： http://localhost:11647/MyService.ashx?sc=OrderService&op=QueryOrder

　　注意：前三種方法，需要在IIS中做些額外的配置，因為URL中不包含文件擴展名了，IIS不知道把請求交給ASP.NET來處理。

　　具體配置見下圖，此處省略78個字。

我對發布服務的5種方式的建議

　　雖然，我給出了5種發布方式，但是我還是想說說我個人的想法。

　　在這些方法中，使用URL重寫，URL路由的方法，并不是我想推薦的，寫它們是主要是為了展示HttpModule 。不推薦它們是因為它們要判斷URL是否符合指定模式，這個判斷是有成本的。至于成本有多高，特此，我專了做門的測試。在示例代碼壓縮包中有個___TestRoutePerformance目錄，結果如何，還是您自己去看吧，我也有點累了。

　　此外，我想問：對于服務來說，URL友好有多大意義？服務的URL會讓用戶來輸入還是讓Google的爬蟲來訪問？

　　如果以上二個問題都是否定的，那么，這二種方法就是在白白浪費機器的性能了。

　　當然了，如果您的站點訪問量不大，那么這點性能也可以忽略不計了，就當我沒說。

　　使用URL重寫URL路由，還有個比較麻煩的事情：如果想通過URL多傳遞一個參數，那么，是不是又要修改URL模式？

　　對于使用DirectProcessRequestMoudle這種模式，我以前已經說過了：除非要很好的理由，否則不建議使用這種方法。

　　至于其它的二種方式，本質上是一樣的，只是說：處理器誰來寫的差別了。

　　不過，如果您要是選擇手工創建一個處理器，除了不用修改web.config之外，還可以自定義URL參數名，可以選擇要不要支持Session

　　【我的服務框架】的一些核心類

　　ReflectionHelper類用于根據類名及服務名定位到一個服務類型以及要調用的方法。

　　因此，它在框架中的作用也是非常關鍵的。

　　internal static class ReflectionHelper

　　{

　　private static List<TypeAndAttrInfo>s_typeList;

　　static ReflectionHelper()

　　{

　　InitServiceTypes();

　　}

　　/// <summary>

　　/// 加載所有的服務類型，判斷方式就是檢查類型是否有MyServiceAttribute

　　/// </summary>

　　private static void InitServiceTypes()

　　{

　　s_typeList = new List<TypeAndAttrInfo>(256);

　　ICollection assemblies = BuildManager.GetReferencedAssemblies();

　　foreach( Assembly assembly in assemblies ) {

　　try {

　　(from t in assembly.GetExportedTypes()

　　let a = (MyServiceAttribute[])t.GetCustomAttributes(typeof(MyServiceAttribute), false)

　　where a.Length >0

　　select new TypeAndAttrInfo {

　　ServiceType = t, Attr = a[0], AuthorizeAttr = t.GetClassAuthorizeAttribute() }

　　).ToList().ForEach(b => s_typeList.Add(b));

　　}

　　catch { }

　　}

　　}

　　private static AuthorizeAttribute GetClassAuthorizeAttribute(this Type t)

　　{

　　AuthorizeAttribute[] attrs = (AuthorizeAttribute[])t.GetCustomAttributes(typeof(AuthorizeAttribute), false);

　　return (attrs.Length >0 ? attrs[0] : null);

　　}

　　/// <summary>

　　/// 根據一個名稱獲取對應的服務類型（從緩存中獲取類型）

　　/// </summary>

　　/// <param name="typeName"></param>

　　/// <returns></returns>

　　private static TypeAndAttrInfo GetServiceType(string typeName)

　　{

　　if( string.IsNullOrEmpty(typeName) )

　　throw new ArgumentNullException("typeName");

　　// 查找類型的方式：如果有點號，則按全名來查找(包含命名空間)，否則只看名字。

　　// 本框架對于多個匹配條件的類型，將返回***個匹配項。

　　if( typeName.IndexOf('.') >0 )

　　return s_typeList.FirstOrDefault(t => string.Compare(t.ServiceType.FullName, typeName, true) == 0);

　　else

　　return s_typeList.FirstOrDefault(t => string.Compare(t.ServiceType.Name, typeName, true) == 0);

　　}

　　private static Hashtable s_methodTable = Hashtable.Synchronized(

　　new Hashtable(4096, StringComparer.OrdinalIgnoreCase));

　　/// <summary>

　　/// 根據指定的類型以及方法名稱，獲取對應的方法信息

　　/// </summary>

　　/// <param name="type"></param>

　　/// <param name="methodName"></param>

　　/// <returns></returns>

　　private static MethodAndAttrInfo GetServiceMethod(Type type, string methodName)

　　{

　　if( type == null )

　　throw new ArgumentNullException("type");

　　if( string.IsNullOrEmpty(methodName))

　　throw new ArgumentNullException("methodName");

　　// 首先嘗試從緩存中讀取

　　string key = methodName + "@" + type.FullName;

　　MethodAndAttrInfo mi = (MethodAndAttrInfo)s_methodTable[key];

　　if( mi == null ) {

　　// 注意：這里不考慮方法的重載。

　　MethodInfo method = type.GetMethod(methodName,

　　BindingFlags.Static | BindingFlags.Instance | BindingFlags.Public | BindingFlags.IgnoreCase);

　　if( method == null )

　　return null;

　　MyServiceMethodAttribute[] attrs = (MyServiceMethodAttribute[])

　　method.GetCustomAttributes(typeof(MyServiceMethodAttribute), false);

　　if( attrs.Length != 1 )

　　return null;

　　// 由于服務方法的參數來源于反序列化，此時只可能包含一個參數。

　　ParameterInfo[] paraInfos = method.GetParameters();

　　if( paraInfos.Length != 1 )

　　throw new ArgumentNullException("指定的方法雖找到，但該方法的參數數量不是1");

　　AuthorizeAttribute[] auths = (AuthorizeAttribute[])method.GetCustomAttributes(typeof(AuthorizeAttribute), false);

　　mi = new MethodAndAttrInfo {

　　MethodInfo = method,

　　ParamType = paraInfos[0].ParameterType,

　　Attr = attrs[0],

　　AuthorizeAttr = (auths.Length >0 ? auths[0] : null)

　　};

　　s_methodTable[key] = mi;

　　}

　　return mi;

　　}

　　/// <summary>

　　/// 根據類型名稱以及方法名稱返回要調用的相關信息

　　/// </summary>

　　/// <param name="pair">包含類型名稱以及方法名稱的對象</param>

　　/// <returns></returns>

　　public static InvokeInfo GetInvokeInfo(NamesPair pair)

　　{

　　if( pair == null )

　　throw new ArgumentNullException("pair");

　　InvokeInfo vkInfo = new InvokeInfo();

　　vkInfo.ServiceTypeInfo = GetServiceType(pair.ServiceName);

　　if( vkInfo.ServiceTypeInfo == null )

　　return null;

　　vkInfo.MethodAttrInfo = GetServiceMethod(vkInfo.ServiceTypeInfo.ServiceType, pair.MethodName);

　　if( vkInfo.MethodAttrInfo == null )

　　return null;

　　if( vkInfo.MethodAttrInfo.MethodInfo.IsStatic == false )

　　vkInfo.ServiceInstance = Activator.CreateInstance(vkInfo.ServiceTypeInfo.ServiceType);

　　return vkInfo;

　　}

　　}

　　ServiceExecutor用于調用服務方法，前面所說的5種服務發布方式，最終都要經過這里。

　　/// <summary>

　　/// 最終調用服務方法的工具類。

　　/// </summary>

　　public static class ServiceExecutor

　　{

　　internal static void ProcessRequest(HttpContext context, ServiceInfo info)

　　{

　　if( context == null )

　　throw new ArgumentNullException("context");

　　if( info == null || info.InvokeInfo == null )

　　throw new ArgumentNullException("info");

　　//if( context.Request.InputStream.Length == 0 )

　　// throw new InvalidDataException("沒有調用數據，請將調用數據以請求體的方式傳入。");

　　if( info.InvokeInfo.AuthenticateRequest(context) == false )

　　ExceptionHelper.Throw403Exception(context);

　　// 獲取客戶端的數據序列化格式。

　　// 默認實現方式：request.Headers["Serializer-Format"];

　　// 注意：這是我自定義的請求頭名稱，也可以不指定，默認為：form (表單)

　　string serializerFormat = FrameworkRules.GetSerializerFormat(context.Request);

　　ISerializerProvider serializerProvider =

　　SerializerProviderFactory.GetSerializerProvider(serializerFormat);

　　// 獲取要調用方法的參數類型

　　Type destType = info.InvokeInfo.MethodAttrInfo.ParamType;

　　// 獲取要調用的參數

　　context.Request.InputStream.Position = 0;// 防止其它Module讀取過，但沒有歸位。

　　object param = serializerProvider.Deserialize(destType, context.Request);

　　// 調用服務方法

　　object result = info.InvokeInfo.MethodAttrInfo.MethodInfo.Invoke(

　　info.InvokeInfo.ServiceInstance, new object[] { param });

　　// 寫輸出結果

　　if( result != null )

　　serializerProvider.Serializer(result, context.Response);

　　}

　　/// <summary>

　　/// 【外部接口】用于根據服務的類名和方法名執行某個請求

　　/// </summary>

　　/// <param name="context"></param>

　　/// <param name="pair"></param>

　　public static void ProcessRequest(HttpContext context, NamesPair pair)

　　{

　　if( pair == null )

　　throw new ArgumentNullException("pair");

　　if( string.IsNullOrEmpty(pair.ServiceName) || string.IsNullOrEmpty(pair.MethodName) )

　　ExceptionHelper.Throw404Exception(context);

　　InvokeInfo vkInfo = ReflectionHelper.GetInvokeInfo(pair);

　　if( vkInfo == null )

　　ExceptionHelper.Throw404Exception(context);

　　ServiceInfo info = new ServiceInfo(pair, vkInfo);

　　ProcessRequest(context, info);

　　}

　　}

　　關于寫框架

　　以前曾在網上見過幾次關于“重復造輪子”的說法?；旧?，全是反對意見。

　　我今天也想談談這個話題：要不要自己寫框架？

　　我的答案是：要。

　　自己寫框架的好處不在于能將它做得多強大，多***，而是從寫框架的過程中，可以學到很多東西。

　　一個框架寫完了，不在乎要給多少人使用，而是自己感覺有沒有進步，這才是關鍵。

　　如果您不重復造輪子，可能永遠不知道造輪子的過程，造輪子需要什么內容。

　　如果不重復造輪子，世界上將只有一個操作系統。

　　如果不重復造輪子，世界上將只有一個數據庫。

　　如果不重復造輪子，世界上將只有一種編程語言。

　　這樣單調會很好嗎？

　　WebForms, MVC, Linq To SQL, Entity Framework, Remoting, Web Service, WCF

　　微軟不也是一直在重復造輪子嗎？

　　結束語

　　終于寫完了這篇博客。這篇博客花了我最多的寫作時間：整整二個周末還加上一些業余時間。

　　當然了，其中也包括實現框架的時間。這其實也是希望更好地展示ASP.NET的核心內容。

　　寫框架不是目標，展示ASP.NET技術，寫博客才是目標哦。

　　因此，這篇博客可謂是【下足了料】，只希望：

　　1. 能給大家分享ASP.NET的核心內容。

　　2. 這篇博客的成績能趕上【細說Cookie】。

　　我的寫博熱情也離不開您的肯定支持哦，如果您認為閱讀此文有收獲，別忘了點一下右下角的【推薦】，【關注 Fish Li】。

　　ASP.NET是個偉大的平臺，能完成許多應用。這些應用的實現離不開這二次博客所提過的核心對象的支持，

　　本來還想再寫點其它的示例，只是時間花得太多了。今天的示例已經很精彩了，到此為止吧，我也想休息了。

　　每個對象都是一個不朽的傳奇，每個傳奇背后都有一個精彩的故事。

　　我是Fish Li, 感謝大家閱讀我的博客，請繼續關注我的后續博客。

　　點擊此處下載示例代碼