上一篇隨筆一書中第三章關於ASP.NET運行原理的補白

上一篇隨筆<深入剖析ASP.NET組件設計>一書中第三章關於ASP.NET運行原理的補白總覽了大體的結構及流程,看完後,相信,可以對整體的流程有所瞭解.但是,許多細節的問題,例如像HttpRuntime如何建立HttpApplication對象等問題,仍然沒有解說清楚
當然,瞭解這些細節並不是必需的,就算你不知道HttpApplication對象是如何被建立的,你仍能夠建立出好的組件.但是,如果你仔佃研究這些細節,相信你會吸收不少技術養分.例如,通過本文講述的HttpApplication對象的建立過程,你就可以深切的體會到ASP.NET設計的精妙之處,並且,你可以學到Factory設計模式的運用,這也是黃先生這本書的另一個特點,就是,他不光講述了ASP.NET的一些東西,同時教你一些編程的方法和技巧,對於一些學習設計模式,而又覺得難以理解設計模式的初學者來說,通過閱讀黃先生的這本書,能夠讓你看到不少設計模式實地運用的講解.

實際上HttpApplication並不是HttpRuntime所建立的.HttpRuntime只是向HttpApplicationFactory提出請求,要求返回一個HttpApplication對象.HttpApplicationFactory在接收到請求後,會先檢查是否有已經存在並空閑(可以這樣講嗎?比較形象一點)的HttpApplication對象,如果有,則從池中取出一個HttpApplication對象返回給HttpRuntime,如果沒有的話,則要建立一個HttpApplication對象給HttpRunTime(英文叫Pooling,好比你養魚一樣,每個魚是一個HttpApplication,而你就是HttpApplicationFactory,別人問你要魚,你就會檢查池中有沒有現成的,並且是合適的魚,有的話,撈一個給別人,沒有的話,創造一條魚,放入池中,再給別人,聽起來不錯,你好像威力無比喲)

實際上,我們再將HttpApplication的建立過程放大來看的話,還有不少細節.上面講述的是HttpApplication是如何被請求以及如何被返回給HttpRunTime的,概括的來說,就是HttpRunTime不直接建立HttpApplication,而是把建立的權利交給HttpApplicationFactory,這裡實際上運用的正是Factory模式,而且不是一般的Factory模式,而是帶有Pool能力的Factory模式.HttpFactory對象負責建立並緩衝HttpApplication對象同時返回合適的對象給HttpRuntime.這裡就有一個問題了,也就是說,同一時刻,HttpApplicationFactory的"養魚池"裡可能有很多個HttpApplication對象.那最多他能夠同時緩衝多少個HttpApplication對象呢?預設情況下,HttpApplication對象的最大緩衝數目為100,並且HttpApplicationFactory會迴圈釋放超過此數量的HttpApplication對象(那是不是意味著超出100個人同時訪問的系統,無論設計的再好,也會因此而遭遇到效能瓶頸呢?)

HttpApplicationFactory建立HttpRuntime的過程是一個Parse與Compile的過程.原書中黃先生說,HttpApplicationFactory會運用Parser對象來解析Global.asax,同時,載入Global.dll檔案,同時,建立一個繼承自此類的原始碼,最後運用Compiler對象來編譯原始碼,再建立一個HttpApplication對象.這一點,也可以從黃先生書中配圖可以看到.但是,估計許多人看到這裡已經暈了.你可以這樣理解這個過程:

首先,黃先生所言的Parser與Compiler對象其實是指Codeparser與CodeCompiler類的兩個執行個體,它們是.net類庫的一部分,Codeparser對象的作用是將一段文本轉換為一段C#或VB原始碼
(
看不懂嗎?有沒有想過,你在ASPX頁面中用<ASP:Label runat=server></ASP:Label>中定義的ASP.NET控制項在運行時究竟變成什麼東東呢?Parser對象可以負責將<asp:Label>以及類似的控制項以及<script runat="server">中的代碼解析成對應的C#源碼片斷,也就是 Label label2=new Label();的形式,它返回一個CodeCompileUnit對象.
如果你仍然不理解ASP.NET的這種Parser行為的話,你就不瞭解ASP.NET控制項的運作形式.你必須深刻的記住一點,那就是,處理對應的ASP.NET頁面請求的不是ASP.NET也不是IIS,更不是ASP.NET頁面本身.而是ASP.NET運用PARSER對象將控制項標記轉換成C#源碼並且派生於PAGE類,被編譯並執行個體外的一個對象.這一點非常重要,跟ASP不同,我們知道ASP的代碼是被載入到記憶體並且被ASP運行時解析然後返回HTML的,但是,ASP.NET不是,ASP.NET處理頁面請求的是一個類的執行個體,它是一個可以輸出HTML的對象.同樣的,在HttpApplication對象的建立過程中,也是運用了Parser,因為HttpApplication實際上要依賴於Global.ASAX檔案,而這個檔案,我們知道,如果不用CodeBehind來寫的話,它就是一個<Script Runat="Server">,換句話來說,它也是一區段標記,這區段標記必須被轉換成C#原始碼,然後編譯成一個類,再產生這個類的執行個體,這個類就是HttpApplication.實際上,像CodeParser,CodeCompiler以及Reflection等構成的CodeDom技術是.NET核心部分之一,.NET的運行非常依賴於這些部分)

至於parser為什麼要解析Global.ASAX同地又要載入Assembly,這一點上,許多人會想不通.因為如果使用CODEBehind技術的話,所有代碼已經包含在Assembly中了呀,為什麼還要解析Global.ASAX呢?如果你這樣想,你就錯了,首先,也可能Global.ASAX中定義了一部分函數,而Assembly中定義了另一部分,其次,沒有人說Gloabal.ASAX中只允許包含代碼呀,也有人喜歡在其中利用OBJECT標記來定義APPLICATION範圍或者Session範圍的對象呀,因此,parser有必要解析Global.ASAX檔案,將其轉換為C#代碼片斷,然後,載入Assembly,利用Reflection技術建立一個繼承自類Global(預設情況下的類名)的新類的原始碼,然後將兩部分的原始碼合并(Ghost Application Class Source),運用Compiler建立出一個新類(Ghost Application Class Assembly),並且產生新類的一個執行個體來返回給HttpRuntime.

原書中,黃先生說Parser會載入Global.dll檔案,我想,這可能是筆誤,很多人不明白Global.dll究竟是什麼.寫過ASP.NET的人更知道,根本沒有這個檔案.我想,Global.dll就是包含global.asax檔案的工程編譯產生的Assembly,由於此Assembly包含了CodeBehind方式下的Global類的資訊.因此,Parser才需要載入它

至此,HttpApplication對象建立完畢了.另外,就AppDomain,HttpRuntime,HttpContext,HttpSession,HttpApplication,HttpModule這些對象的數量以及與使用者數量的對應關係做以下描述
每一個ASP.NET只有一個AppDomain,每一個AppDomain對應一個httpRunTime,它們都與使用者數量無關
每一個使用者對應一個HttpApplication,一個HttpSession,一個HttpContext和一組HttpModule

如果對於HttpApplication對象產生過程中的Parser與Compiler不清楚的話(這部分很重要,包括AspX頁面的處理方法也是類似的),下面的圖或許有助理解: