PageMethods 與 XMLHttpRequest
上一篇提到利用PageMethods方來進行Ajax非同步，進而實現ProgressBar的應用，但實際上仍不盡完美，怎麼說呢？
主要是在運作時，仍發現一開始進行非同步呼叫時會有部份延遲的現像，並不如想像中的順暢，使用HttpWatch Tool可以發現
，在每15秒就呼叫一次非同步的情況下(事實上希望能達到每10秒就呼叫一次)，前幾次的呼叫從send到receive完成的時間
，最高來到95秒左右，換言之在這95秒內，頁面早已又呼叫好幾次，並且均尚未回應
這個情況使得我開始思考一件事情
在Asp.net Ajax非同步的做法裡，大致有下列幾種
1.UpdatePannel : 不適用在本需求裡，原因很簡單，它的運行原理無法達到很好的效能
2.利用PageMethods.xxx方式：一開始所採行的做法
3.以XMLHttpRequest進行：本需求裡最後的做法
一開始扣除UpdatePannel，在方法2及3的選擇上，原先認為從program的角度二種方式的原理都是類似call web service的方法
，差別是在於call PageMethods.xxx方式是將處理的Logic寫在原本的page頁面，而以XMLHttpRequest的方式則是必須另call
另一隻aspx or ashx，所以在方式的選擇上當遇到需要共用到的情況下則採用XMLHttpRequest的方式，若是單一隻頁面本身
所需的部份則以javascript call PageMethods.xxx方式來提供
若是方法2及3的選擇差別僅在上述的論點時，那麼為何會有這個不順暢問題的出現呢？
於是立即做了一個測試，改以方法3進行，再利用HttpWatch Tool進行觀察
結果非同步的呼叫很順暢，沒有一開始會延遲的現象，此外將呼叫時間改為每10秒即呼叫一次測試
結果依然令人滿意，且從send 到 receive的時間均在0.0x秒以內
除此之外send size大小也比方法2來的小一些，receive size則差不多
至此打破了我原先的認知(認為二者差異不大)，事實上卻不盡然
首先利用PageMethods.xxx方式進行非同步，在程式撰寫上除了page上的[System.Web.Services.WebMethod] static method的選寫之外
在前端的javascript部份幾乎不太需要多寫些什麼，除了PageMethods.xxx的呼叫及相對應的Success、Fail所需的function之外，會發
現並沒有告知要如何傳送及什麼型態傳送接收等等的宣告或定義，原來此部份推論應該是由ScriptManager處理掉了，更正確的說法應
該是由Asp.net Ajax 一併包裝處理了，怎麼說呢?
我們可以來看一下當採用PageMethods.xxx方式進行非同步時，必須把ScriptManager的屬性EnablePageMethods="True"，如此一來在
前端所顯示後aspx page上，檢視一下原始檔，可以發現到自動添加了以下的code，諸如PageMethods.initializeBase(this);之類的
而以XMLHttpRequest進行非同步的撰寫，則完全依賴開發人員撰寫ActiveXObject、XMLHttpRequest等code，以及相關的宣告或定義
因此據以推論雖然利用PageMethods.xxx方式及以XMLHttpRequest進行非同步，看似均雷同但實際上，一者還是有經過包裝，而另一者
則完全沒有，在Loading上還是具有差別的
經由本次的經驗使得對於二者的差別在觀念上的誤差得到了校正，更重要的是在開發方式上的選擇重新多了一個更正確的判斷經驗
若有錯誤，請不吝指正，感謝
參考資源：
asp.net jquery jQuery and asp.net ajax 结合使用
使用 AJAX Extensions 用戶端 Web 服務呼叫
使用 ASP.NET 部分呈現功能進行 AJAX 的程式設計
Consuming ASP.net WebServices, WCF Services and static Page methods from JavaScript (sans MS AJAX)
Exposing Web Services to Client Script
By No.18