這一章是全書基礎和精神所在,其後的例子章節是爲了驗證這章的講述和實踐講述的內容
其中第一節是講述ASP.NET運行模式,這一節着眼於整個ASP.NET應用程序的運作模式,實際上,並不是在講組件,但是卻很重要,因爲寫組件的人必須清楚的知道ASP.NET應用程序是如何啓動.如何處理請求,如何處理SESSION等這些細節問題的,但這一節對於一般讀者來講,可能十分晦澀.下面的講解可能有助於你理解這一切.
一個ASP.NET的應用程序是開始於IIS的.
當你請求一個包含ASP.NET應用的網址時,IIS接受到請求(IIS是WEB服務守候進程),IIS收到請求後,會根據請求者請求的主機頭或者IP或者端口號來找到對應的站點.
當找到站點後,如果你請求的資源是以ASPX爲結尾的WEBFORM,時,IIS會將控制權交給一個ISAPI擴展.,名叫AspNet_ISAIP.DLL.這時,控制權由IIS交到ASPNET的ISAPI擴展上.,需要說明的是,ISAPI擴展的級別低於IIS,但高於用戶站點,它獨立於站點之外
ISAPI收到處理請求後,會啓動一個ASP.NET工作進程.然後將請求者的請求信息轉交給ASP.NET工作進程(名爲ASPNET_WP.EXE).接下來,控制權由ASPNET_WP掌握.ASPNET_WP首先解出請求者的信息,如果請求者請求的ASP.NET應用程序(站點或虛擬目錄,通俗一點)尚未擁有APPDOMAIN,ASPNET_WP就會建立一個APPDOMAIN,並且將被請求的ASP.NET應用所需的Assembly(就是那些DLL,例如System.Web.DLL等)載入到APPDOMAIN中
以上的步驟可以看到一個結論和規律:控制權是以流水式在各個請求處理者間傳遞,並且,前一個處理請求者必須負責傳遞後一個處理請求者所需的信息.而且要負責裝載或初始化後一個處理者,這很像我們生活中的接力賽.
問題是,可能有許多人會問:幹嘛要如此繁瑣呢?直接由IIS把請求轉交給ASPNET_WP如何呢?不是不可以,而是如此一來,這個處理過程的可擴展性就變低了.ASPNET ISAPI是IIS和ASPNET_WP之間的橋樑.雖然看起來它僅僅負責轉交請求等工作.可是這樣一來,就大大擴展延展性.
另外一個疑問是關於APPDOMAIN的,包括我,對於APPDOMAIN一開始的理解就曾陷入誤區,APPDOMAIN這東東微軟講的也比較含糊,有人說跟進程一樣,但我一開始理解成了IIS裏的應用程序池,所以,走了不少彎路,實際上,APPDOMAIN既不是進程,也不是IIS裏的應用程序池概念..NET下的所有應用程序都運行於APPDOMAIN之中(我自己的理解),每一個APPDOMAIN是一個執行的容器,每執行一個應用程序或者ASP.NET應用,.NET執行環境就會建立一個APPDOMAIN,然後把應用程序需要的一些DLL載入.APPDOMAIN的功能很像進程,但絕不是進程.你可以這樣理解,APPDOMAIN就是ASP.NET應用程序的執行環境吧.
AspNet_WP不光負責建立APPDOMAIN(當然,如果已經存在的話,就直接使用這個DOMAIN了)，另外，它在APPDOMAIN建立後，還會將請求轉發至對應的APPDOMAIN中的ISAPIRuntime對象。(Isapiruntime對象是APPDOMAIN的一部分)。ISAPIRUNTIME專門負責解出請求的必要信息。它將信息和請求轉交給HttpRuntime。在這裏，需要說明的是IsapiRuntime是一個類，它的全稱是System.Web.Hosting.ISAPIRuntime，而HttpRuntime也是一個類，它的全稱是System.Web.HttpRuntime。因此，可以說，這兩個對象是APPDOMAIN運行環境的一部分，在ASPNET_WP建立APPDOMAIN的同時,也會作爲運行環境來建立這兩個對象.
由於接二連三的講述了幾個對象,所以,當我第一遍看這本書特別是看到這部分時,覺得特別暈,因爲第一對.NET FRAMEWORK的類庫不甚瞭解,第二,對ASP.NET的運行原理初次接觸.摸不着頭腦,總想把這些對象名稱與某個DLL或者某個實際上的文件來對應.其實不然,不管是ISAPIRuntime也好,還是HttpRuntime,它們在APPDOMAIN建立時,作爲APPDOMAIN的一部分被實例化.所以它們代表的是內存中的一個類的實例,也就是對象.並且,這上面的一部分運作原理,似乎跟ASP.NET應用程序沒有直接聯繫.似乎不入正題,很容易讓初看者不知所云.實際上,可以說,由IIS到ISAPI是完成了請求的第一個部,也就是接納客戶請求.由ISAPI到APPDOMAIN,是第二部分,也就是初始化部分,旨在建立處理請求的大環境,爲下面處理請求和運行ASP.NET應用程序作好準備.
接下來,當APPDOMAIN初始化完成後,接下來就需要建立會話了吧,因此,請求由HttpRuntime來接受,HttpRunTime主要的工作便是爲每一個提出請求的客戶建立一個HttpContext對象.這個東東又管理着HttpSession對象.每一個訪問者有各自的HttpContext對象和HttpSession對象,這些對象,你可以在.NET FRAMEWORK庫中找到對應的類名,像System.Web.HttpContext,System.Web.HttpSessionState等.
可以看出,請求的處理過程非常類似於.NET中事件模型的處理過程.若干個處理模塊被串接到一個事件上.在ASP.NET運行原理裏,也是,若干個模塊依次輪流處理一個請求,像流水線操作一樣.
另外,作爲組件開發者,還要明確一個HttpRuntime,HttpContext,HttpSession這些對象的層次關係和調用創建關係.細節部分無需瞭解,只要知道誰創建了誰,誰被誰調用即可
HttpRuntime負責創建HttpContext和HttpSession,httpContext負責管理httpSession
到HttpRuntime創建完httpContext爲止,實際上,你的應用程序仍然沒有運行,或者說,請求者的請求實際上並未真正的被處理,前面的工作都是些準備性或者輔助性的工作.
HttpRuntime除了創建上面的對象外,還要創建HttpApplication.至於創建Application對象的過程,是比較複雜的.你可以把其作爲一個分支流程涉略一下
接下來,HttpApplication調用ProcessRequest方法來處理用戶請求,此方法會調用對應的HttpHandler來處理用戶請求,HttpHandler根據用戶請求的文件的擴展名處理請求,並把請求的結果,也就是HTML發送到客戶瀏覽器
另外,過程的複雜性遠遠超出了上面的描述,基本上,黃先生這本書的第三章第一節用了十幾頁文本在描述ASP.NET運行過程及原理,以及處理請求時用的一些手法,但總體上的過程如上面的描述那樣,只不過,我沒有將建立各種對象時的細節剝離出來展示給大家.黃先生原著上的這節內容實際上非常詳細.但爲何大家看起來均言吃力呢?一方面是因爲原理部分一向比較麻煩,另外一方面,是因爲黃先生在講述時,沒有先向大家概要的描述過程和綱領,然後再描述細節,再是直接把細節和綱領融合在一起.這樣,如果看的時候,沒有去將這節的各個小標題和內容串聯起來並先總結出綱領來的話.看完後,就會頭暈.實際上,整個講述就是在描述ASP.NET處理請求的過程.如果隱藏所有技術性的細節,而只講流程的話,大家可能很快理解.然後再將流程中的每一部分的技術細節展現出來,我想,容易理解的多.這好比講故事,先將故事梗概說一下比較好吧.
當然,我不是說黃先生寫的不好,實際上,這一節寫的很透徹,看懂了,就很受用.流程是很重要的,它的重要性在於你知道了在何時發生何事,就可以在指定的時間點做一些處理.這一點,在黃先生本書以後的章節中講述ASP.NET PAGE對象執行流程中更顯重要.
下面的圖對整個ASP.NET應用運行過程中的各個對象的職能以及流程做了圖解.當然,圖解拋棄了技術性的細節,例如,像HttpApplication如何建立等
![]()
補充的圖片
