建站
咨詢
售后
建站咨詢
新聞中心
ASP.NET AJAX的許多功能會要求異步地訪問服務器端，例如訪問Web Services，Authentication/Profile Services（事實上和訪問Web Services是相同的機制）和Partial Rendering。在ASP.NET AJAX中，所有的這些訪問都是通過一個網(wǎng)絡訪問的基礎結(jié)構來完成的，無一例外。
10年積累的成都做網(wǎng)站、網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設經(jīng)驗，可以快速應對客戶對網(wǎng)站的新想法和需求。提供各種問題對應的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡服務。我雖然不認識你，你也不認識我。但先網(wǎng)站設計后付款的網(wǎng)站建設流程，更有渾源免費網(wǎng)站建設讓你可以放心的選擇與我們合作。
一般來說，ASP.NET AJAX提供的類已經(jīng)足夠大多數(shù)應用的需求，但是在某些特殊情況，可能需要做一些改變。因此，Network Communication Layer提供了一定程度上的擴展能力——通過提供自定義的WebRequestExecutor子類來替換默認設置：XMLHttpExecutor。這種改變能夠應用于一個單獨的WebRequest，也可以對全局進行一個設置。這個我們就能對于客戶端的行為做一些簡單的修改和補充。這樣可以說是 Network Communication Layer唯一的“官方”擴展點，其實能力有限。至于使用一些靈活的辦法從JavaScript語言特性能上進行的修改，在這里就忽略不計了。
這樣我們就能對于客戶端的行為做一些簡單的修改和補充。那么如果對其進行大量的修改會怎么樣？如果這種修改的確能夠滿足您的需要，當然可以?？墒沁@樣的話，Partial Rendering就很可能無法實現(xiàn)了。Partial Rendering的作法是在客戶端和服務器端產(chǎn)生一個嚴謹?shù)膮f(xié)議，用來傳遞和處理大量的數(shù)據(jù)。如果有任何改變被加諸于這些數(shù)據(jù)上，協(xié)議就被破壞了，這個可以說是ASP.NET AJAX的最重要的功能之一的控件也就失效了。
接下來，我們詳細了解一下這整個流程的每個步驟。
一、創(chuàng)建Sys.Net.WebRequest
這是發(fā)起一個服務器請求的***步。首先建立一個Sys.Net.WebRequest對象，然后通過addHeader，set_url等方法設置這個請求的各個信息，然后調(diào)用add_complete方法來注冊complete事件。請注意，這和CTP版本的Sys.Net.WebRequest不同。在CTP版本的Sys.Net.WebRequest中，存在著三個事件：complete，timeout和aborted，用戶可以有選擇地注冊這些事件。在RTM的Sys.Net.WebRequest中，三個事件被合成了一個complete事件。不管這個Request的結(jié)果如何，都會在這個觸發(fā)這個事件，用戶需要在響應這個事件的方法里自行根據(jù)得到的Response的信息來分辨這個請求的狀況。具體的判斷方式稍后再進行說明。在創(chuàng)建完 WebRequest對象后，將調(diào)用它的invoke方法執(zhí)行這個請求。一個WebRequest對象只能被 invoke一次。
二、將WebRequest對象交給WebRequestManager執(zhí)行
在WebRequest對象的invoke方法被調(diào)用以后，它會調(diào)用 “Sys.Net.WebRequestManager.executeRequest(this)”將自身交給全局的 WebRequestManager執(zhí)行。這里的WebRequestManager其實是Sys.Net._WebRequestManager類的實例。在初始化環(huán)境的時候，就會將這個類實例化一個對象，賦值到Sys.Net.WebRequestManager變量中，以一個Singleton的形象供別的方法調(diào)用。它會在處理Request的過程中在特定的時刻觸發(fā)一些事件，用戶可以依靠響應這些事件來改變Request的行為，例如阻止特定的 Request，或者改變Request的一些屬性等等。
乍看下來，RTM版本中的WebRequestManager和CTP中的 WebRequestManager沒有很大的區(qū)別嘛（引入了幾個事件除外）。事實上，個人認為在這個方面Atlas打了自己一個耳光。在CTP版本的 WebRequestManager中，對于管理WebRequest有一套比較復雜的方法，其理由是能夠更好地利用好瀏覽器的資源，以提高 WebRequest的效率。這就是Atlas對外一直聲稱的“Client Request Stack”，這一點被當作Atlas的重要特點來看待。不過這一點在RTM版本中被取消了，新的WebRequestManager在處理一個 WebRequest對象的時候僅僅是觸發(fā)事件，然后簡單地使用Executor來調(diào)用這個WebRequest對象。
下面列舉了調(diào)用了executeRequest方法后的關鍵邏輯：
1. 檢查WebRequest是否指定了WebRequestExecutor（這可以在構造WebRequest的時候指定）。
2. 如果WebRequest沒有指定WebRequestExecutor，則使用set_executor方法分配默認的WebRequestExecutor
3. 構造Sys.Net.NetworkRequestEventArgs參數(shù)對象，觸發(fā)WebRequestManager的invokingRequest事件。
4. 如果Sys.Net.NetworkRequestEventArgs對象的cancel屬性為true，取消執(zhí)行Request。
5. 調(diào)用executor對象的executeRequest方法，以執(zhí)行Request。
三、WebRequestExecutor執(zhí)行Request
在這里，以ASP.NET AJAX的默認WebRequestExecutor類：XMLHttpExecutor為例進行說明。在XMLHttpExecutor的 executeRequest方法被調(diào)用后，XMLHttpExecutor會構造一個XMLHttpRequest對象，并根據(jù)WebRequest的各項屬性設定XMLHttpRequest的對象，并指定XMLHttpRequest對象的onreadystatechange為自身的私有方法 _onReadyStateChange。調(diào)用了executeRequest方法后的關鍵邏輯如下：
1. 構造XMLHttpRequest對象，并根據(jù)WebRequest對象的屬性設定它的各項屬性。
2. 使用window.setTimeout用于監(jiān)聽超時發(fā)生。
3. 調(diào)用XMLHttpRequest的send方法。
在timeout的響應方法中調(diào)用XMLHttpRequest的abort方法，并調(diào)用WebRequest的complete方法。在 _onReadyStateChange方法中清除監(jiān)聽timeout的Timer，并調(diào)用complete方法。當然，這只是個簡單的描述，事實上還需要對Executor的屬性進行設定。我們將在下篇文章中將對此進行詳細討論。在complete方法被調(diào)用后關鍵邏輯如下：
1. 觸發(fā)WebRequestManager的completedRequest事件。
2. 觸發(fā)WebRequest的complete事件。
四、用戶響應WebRequest的complete事件
在響應WebRequest的complete事件時，需要對于所獲得的結(jié)果進行判斷，以確定這個Request的結(jié)果到底如何，是成功了，還是出錯了，亦或是過期了？需要注意的是，我們雖然監(jiān)聽的是WebRequest對象的事件，但是回調(diào)函數(shù)的***個參數(shù)是WebRequestExecutor對象！executor對象在這里事實上應該被看作是一個response。我們就來簡單看一下應該如何根據(jù)executor對象的屬性來判斷 Request的結(jié)果吧。為了對于這部分邏輯有簡單而清晰的描述，我就使用代碼片斷來說明吧。代碼框架如下：
- 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結(jié)果的邏輯框架了，非常清晰。閱讀過ASP.NET AJAX客戶端代碼的朋友們可以發(fā)現(xiàn)，在RTM版本中這段邏輯不只一次出現(xiàn)過。我們?nèi)绻枰苯邮褂肳ebRequest對象時，也應該使用這個邏輯進行判斷。
到這里，我們應該已經(jīng)搞清楚了從一個WebRequest對象被構造出來以后，是如何通過WebRequestManager和 WebRequestExecutor而執(zhí)行的，之間會觸發(fā)哪些事件，而***又是如何通過Response（WebRequestExecutor）對象來獲得Request的結(jié)果。在下一篇文章中，我們將通過分析WebRequestExecutor、XMLHttpExecutor以及相關類的實現(xiàn)，來了解應該如何自定義和使用一個WebRequestExecutor。
分享文章：淺析ASP.NETAJAX
標題鏈接：http://www.5511xx.com/article/dpogpgg.html
