淺析ASP.NET AJAX
ASP.NET AJAX的許多功能會要求異步地訪問服務器端，例如訪問Web Services，Authentication/Profile Services（事實上和訪問Web Services是相同的機制）和Partial Rendering。在ASP.NET AJAX中，所有的這些訪問都是通過一個網絡訪問的基礎結構來完成的，無一例外。
一般來說，ASP.NET AJAX提供的類已經足夠大多數應用的需求，但是在某些特殊情況，可能需要做一些改變。因此，Network Communication Layer提供了一定程度上的擴展能力——通過提供自定義的WebRequestExecutor子類來替換默認設置：XMLHttpExecutor。這種改變能夠應用于一個單獨的WebRequest，也可以對全局進行一個設置。這個我們就能對于客戶端的行為做一些簡單的修改和補充。這樣可以說是 Network Communication Layer唯一的“官方”擴展點，其實能力有限。至于使用一些靈活的辦法從JavaScript語言特性能上進行的修改，在這里就忽略不計了。
這樣我們就能對于客戶端的行為做一些簡單的修改和補充。那么如果對其進行大量的修改會怎么樣？如果這種修改的確能夠滿足您的需要，當然可以。可是這樣的話，Partial Rendering就很可能無法實現了。Partial Rendering的作法是在客戶端和服務器端產生一個嚴謹的協議，用來傳遞和處理大量的數據。如果有任何改變被加諸于這些數據上，協議就被破壞了，這個可以說是ASP.NET AJAX的最重要的功能之一的控件也就失效了。
接下來，我們詳細了解一下這整個流程的每個步驟。
一、創建Sys.Net.WebRequest
這是發起一個服務器請求的***步。首先建立一個Sys.Net.WebRequest對象，然后通過addHeader，set_url等方法設置這個請求的各個信息，然后調用add_complete方法來注冊complete事件。請注意，這和CTP版本的Sys.Net.WebRequest不同。在CTP版本的Sys.Net.WebRequest中，存在著三個事件：complete，timeout和aborted，用戶可以有選擇地注冊這些事件。在RTM的Sys.Net.WebRequest中，三個事件被合成了一個complete事件。不管這個Request的結果如何，都會在這個觸發這個事件，用戶需要在響應這個事件的方法里自行根據得到的Response的信息來分辨這個請求的狀況。具體的判斷方式稍后再進行說明。在創建完 WebRequest對象后，將調用它的invoke方法執行這個請求。一個WebRequest對象只能被 invoke一次。
二、將WebRequest對象交給WebRequestManager執行
在WebRequest對象的invoke方法被調用以后，它會調用 “Sys.Net.WebRequestManager.executeRequest(this)”將自身交給全局的 WebRequestManager執行。這里的WebRequestManager其實是Sys.Net._WebRequestManager類的實例。在初始化環境的時候，就會將這個類實例化一個對象，賦值到Sys.Net.WebRequestManager變量中，以一個Singleton的形象供別的方法調用。它會在處理Request的過程中在特定的時刻觸發一些事件，用戶可以依靠響應這些事件來改變Request的行為，例如阻止特定的 Request，或者改變Request的一些屬性等等。
乍看下來，RTM版本中的WebRequestManager和CTP中的 WebRequestManager沒有很大的區別嘛（引入了幾個事件除外）。事實上，個人認為在這個方面Atlas打了自己一個耳光。在CTP版本的 WebRequestManager中，對于管理WebRequest有一套比較復雜的方法，其理由是能夠更好地利用好瀏覽器的資源，以提高 WebRequest的效率。這就是Atlas對外一直聲稱的“Client Request Stack”，這一點被當作Atlas的重要特點來看待。不過這一點在RTM版本中被取消了，新的WebRequestManager在處理一個 WebRequest對象的時候僅僅是觸發事件，然后簡單地使用Executor來調用這個WebRequest對象。
下面列舉了調用了executeRequest方法后的關鍵邏輯：
1. 檢查WebRequest是否指定了WebRequestExecutor（這可以在構造WebRequest的時候指定）。
2. 如果WebRequest沒有指定WebRequestExecutor，則使用set_executor方法分配默認的WebRequestExecutor
3. 構造Sys.Net.NetworkRequestEventArgs參數對象，觸發WebRequestManager的invokingRequest事件。
4. 如果Sys.Net.NetworkRequestEventArgs對象的cancel屬性為true，取消執行Request。
5. 調用executor對象的executeRequest方法，以執行Request。
三、WebRequestExecutor執行Request
在這里，以ASP.NET AJAX的默認WebRequestExecutor類：XMLHttpExecutor為例進行說明。在XMLHttpExecutor的 executeRequest方法被調用后，XMLHttpExecutor會構造一個XMLHttpRequest對象，并根據WebRequest的各項屬性設定XMLHttpRequest的對象，并指定XMLHttpRequest對象的onreadystatechange為自身的私有方法 _onReadyStateChange。調用了executeRequest方法后的關鍵邏輯如下：
1. 構造XMLHttpRequest對象，并根據WebRequest對象的屬性設定它的各項屬性。
2. 使用window.setTimeout用于監聽超時發生。
3. 調用XMLHttpRequest的send方法。
在timeout的響應方法中調用XMLHttpRequest的abort方法，并調用WebRequest的complete方法。在 _onReadyStateChange方法中清除監聽timeout的Timer，并調用complete方法。當然，這只是個簡單的描述，事實上還需要對Executor的屬性進行設定。我們將在下篇文章中將對此進行詳細討論。在complete方法被調用后關鍵邏輯如下：
1. 觸發WebRequestManager的completedRequest事件。
2. 觸發WebRequest的complete事件。
四、用戶響應WebRequest的complete事件
在響應WebRequest的complete事件時，需要對于所獲得的結果進行判斷，以確定這個Request的結果到底如何，是成功了，還是出錯了，亦或是過期了？需要注意的是，我們雖然監聽的是WebRequest對象的事件，但是回調函數的***個參數是WebRequestExecutor對象！executor對象在這里事實上應該被看作是一個response。我們就來簡單看一下應該如何根據executor對象的屬性來判斷 Request的結果吧。為了對于這部分邏輯有簡單而清晰的描述，我就使用代碼片斷來說明吧。代碼框架如下：
- functiononComplete(response,eventArgs){
- if(response.get_aborted()){
- //Abort
- }
- elseif(response.get_responseAvailable()){
- varstatusCode=response.get_statusCode();
- if(((statusCode<200)||(statusCode>=300))){
- //Error
- }
- else{
- //Success
- }
- }
- else{
- if(response.get_timedOut()){
- //Timeout
- }
- else{
- //Error
- }
- }
- }
這就是判斷一個Request結果的邏輯框架了，非常清晰。閱讀過ASP.NET AJAX客戶端代碼的朋友們可以發現，在RTM版本中這段邏輯不只一次出現過。我們如果需要直接使用WebRequest對象時，也應該使用這個邏輯進行判斷。
到這里，我們應該已經搞清楚了從一個WebRequest對象被構造出來以后，是如何通過WebRequestManager和 WebRequestExecutor而執行的，之間會觸發哪些事件，而***又是如何通過Response（WebRequestExecutor）對象來獲得Request的結果。在下一篇文章中，我們將通過分析WebRequestExecutor、XMLHttpExecutor以及相關類的實現，來了解應該如何自定義和使用一個WebRequestExecutor。
【編輯推薦】
