AJAX開發工具對比（僅限.net環境）

--==前言==--來源：Yesky 

 參考文章：AJAX架構匯總

　　在這裡我將試圖考察一下目前.NET平台的下的Ajax架構，我也試圖從中總結出來一種方法，使得你可以在眾多基於.NET平台的Ajax架構和工具包中找到你所合適的一種，同時也希望你在考察、預研和使用這些流行的這些Ajax-NET 的架構時，做得理性和有的放矢。

　　我想，文章的方法會給目前使用Ajax的.NET使用者帶來協助，從而提高你在.NET平台下使用Ajax的體驗。為什麼這麼說，因為最近我的一個客戶(應該是一些客戶)的研發主管對我說，我們對Atlas 非常興趣，想瞭解更多一些相關的內容和如何開始看待Atlas，因為下個月會來一個Atlas的專家和我們交流。因為我知道這個主管手上掌握著一個Ajax架構的業務應用，目前在考慮從.NET v1.1遷移到.NET v2.0，Atlas能在怎樣的程度上幫忙他或他的Team?我沒有說太多，因為心裡我有些吃驚，目前的他們的架構應用Atlas 可能並不是一個明智的選擇，當然這個擔心基於我目前對Atlas的理解。

　　我列舉和討論的Ajax-NET的架構和工具包括Atlas(Jan CTP), Anthem.NET, MagicAjax.NET , Ajax.NET Professional 和wwHoverPanel Control，這基本都是我關注的.NET平台的下的Ajax 的一些架構和實現。 基本上也都是我的這篇文章中列舉的，另外一個原因是因為他們基本上都是開源的，這個非常重要，因為沒有原始碼，我們將不知道究竟發生了什麼。另外我無意於使之成為像Daniel Zeiss作的這個比較報告。

　　首先，開門見山的說明我的觀點。

　　對於開源或現有的Ajax-NET技術或架構的選用必須針對你目前應用的架構來選取和考慮，如果你目前的架構是"似Ajax"的，那麼你在選擇現在所有流行的Ajax-NET的技術的時候都必須非常小心;而如果你目前的應用是使用傳統的ASP.NET的應用架構(或準備用ASP.NET v2.0開始建立新的應用)，那麼目前流行的Ajax-NET的架構和技術都是普遍適合的，關鍵你要在合適的時機選擇合適的某個架構或實現。

　　在我的眼中，目前流行的Ajax-NET的架構或實現都是Add-in (Plug-in)的模式的，也就是說這些架構對於所有後一種即使用傳統的ASP.NET的應用架構(或準備用ASP.NET v2.0開始建立新的應用)是Awared的也就是非常有利和方便的。但對於"似Ajax"的架構來說，情況有所不同，需要你從另外的角度來衡量，有選擇的使用。

　　那什麼是"似Ajax" 的架構呢，這就是說，你的應用程式是在Ajax概念提出之前就建立的。從用戶端和伺服器端的互動分析來說，你的用戶端有大量的Javascript 代碼接受XML資料，進行對象的序列化，然後使用Javascript配合其它的HTML技術展現這些對象和資料，也可能你還有一堆HTC或其它的Javascript的HTML表現層控制項。你的伺服器端是一個Facade(或者是Adapter,Observer)模式的(Handler)控制器，接收用戶端Javascript的XML請求資料後，然後解析XML，然後調用相應的某個服務或業務組件，再將結果以XML的形式返回給用戶端Javascript ，用戶端的Javascript接收之後，再進行處理和顯示，因為可以使用HTML的DOM 和CSS，所有頁面的展現是動態。

　　這樣用戶端是中描述的Script-centric architecture 或Data-centric interactions 的方式。而且這種方式和Jesse James Garrett列舉的Ajax 是最類似的，只不過那時你或我不知道這個可以叫Ajax，只不過是現在的人誤解了Ajax，Ajax成了一種技術，一種特性，而首先不是一種某種架構下Web 應用程式了。

　　而且目前流行的Ajax-NET的架構基本上都沒有實現雙向序列化，因為實現一個TextBox的自動完成用戶端只用接收資料就行了，根本不用傳回資料/對象到伺服器端，同樣做一個Ajax的狀態進度條也不用，但這些都是Ajax啊，我們衡量的標準是非同步、頁面沒有重新整理。

　　很抱歉，我用了這麼字才解釋完我的觀點。最後可以這麼說，如果你的應用已經是Ajax架構的，那麼你需要仔細選擇使用目前的Ajax-NET架構，確保它也提供雙向序列化功能，相容你原來的應用和架構。如果你的應用不是Ajax架構的，那麼你可以依據一些條件來選擇Ajax-NET架構。

然後我們回到文章的開始，來看一些流行的Ajax-NET架構

　　1. MagicAjax.NET

　　這是目前架構中版本號碼最小的一個Ajax-NET實現，許多人很喜歡它，甚至一見如故，但真的看過它的代碼之後，我有些擔憂。

　　MagicAjax.NET基於這樣一種策略，即__doPostBack 會提及整個的ASP.NET頁面，這樣會導致頁面重新整理，所以MagicAjax.NET使用AJAXCbo.DoPostCallBack 做局部的提交，而每個AjaxPanel 中的內容則對應用戶端即時的HTML內容，因為在MagicAjax.NET中，用戶端只用執行eval(responseText) 伺服器端Rendered返回的HTML就可以了(很被動)。

　　由於DoPostCallBack 會提交ViewState 以及AjaxPanelx$RBS_Store，幾乎是用XMLHttpRequest 類比一個正常的提交，所以伺服器端可以建立頁面的執行個體也可以根據ViewState 恢複所有的控制項狀態，同樣AjaxPanel 以及AjaxControl 也都會執行個體化，然後接收用戶端傳來的_EventTarget, _EventArgument 走正常的ASP.NET控制項的處理過程，等控制項Rendered之後，最終的HTML輸出被傳回用戶端，然後被用戶端的eval 顯示出來。

　　整個過程非常巧妙，這幾乎是ASP.NET __doPostBack 的"Hook ASP.NET"版和加強版本。而HttpModel 主要是為瞭解決Session和交叉提交，進行用戶端Javascript的整理和注入，當然也是這裡接收用戶端的請求，在Application_EndRequest中返回結果。剩下的代碼都是處理控制項在VS Web Design中的設計時支援。AjaxCallObject.js 和WebParts.js 每次都要傳到用戶端。

　　MagicAjax.NET 的一些不足和想法:

• 　　1、__doPostBack 的加強版，適合於ASP.NET的進階使用者使用
• 　　2、由於和ASP.NET的頁面處理機制依賴非常密切，控制項的預設動作發生變化則可能不工作，比如第三方的某個自訂控制項;
• 　　3、依賴ViewState ，如果是加密的ViewState，則可能工作不正常，我沒有試，在代碼中好像沒有看見__VIEWSTATEENCRYPTED
• 　　4、是對ASP.NET 全部頁面提交的最佳化，實現有限的Ajax功能，可擴充性不大

　　如果是基於ASP.NET 提供的控制項和開發，那麼MagicAjax.NET 是非常有效，很好的解決了Session和跨頁面狀態的問題。而且用戶端的操作和工作基本可以忽略，MagicAjax.NET設計貼近最近的ASP.NET的版本，目前不提供調用用戶端直接調用頁面的方法。但隨著其發展，優勢可能漸少，因為Atlas 最新的版本提供類似的UpdatePanel 控制項。

我沒有看過Ajax.NET Professional 的原始碼，但從例子中看得其支援調用頁面的某個方法，以及返回對象，DataSet，DataTable的資料，我認為Ajax.NET Professional 的實現和Anthem.NET 原理是一樣的，雖然Ajax.NET Professional 使用了HTTP Model，這個只是和Anthem.NET 一樣，最終處理結果的返回處理上稍有不同不同。比較起來，Ajax.NET Professional 沒有重新繼承所有常用的ASP.NET控制項實現部分提交的功能，所以可能Ajax.NET Professional 比較強項的是調用頁面上的某個方法，並在用戶端獲得結果的資料，這個已經夠實現大部分的Ajax的功能了。

　　從這個層面上看，我認為Ajax.NET Professional 是相對笨重和複雜了。Anthem.NET不使用HTTP Model，提供控制項基本的局部提交，也提供資料層面的用戶端方法調用。Ajax.NET Professional 的原始碼似乎總是不想共用 ，這也是我不喜歡它的另外一個原因。

　　無論如何，大家都沒有提供兩路的資料交換，即用戶端可以獲得伺服器端的方法並獲得結果和資料，但是目前都支援將這些對象/資料修改之後返回給伺服器端。

　　Anthem.NET 的一些不足和想法:

• 　　1) Anthem.NET 也是一種"Hook ASP.NET"原理，旨在彌補ASP.NET的整頁面的提交和PostBack，並且在用戶端的資料訪問和互動上做了加強。
• 　　2) Anthem.NET需要重新將ASP.NET提供的控制項進行繼承和封裝，所以使用和功能的相容性上非常敏感。
• 　　3) 也許微軟下個版本的ASP.NET的標準控制項可以借鑒Anthem.NET的做法，給各個控制項增加這個遠程回調的介面。
• 　　4) 目前版本的功能已經非常強大和略有些複雜了，而且部署比較方便，無需設定HTTP Model。

　　3. wwHoverPanel AJAX Control for ASP.NET

　　wwHoverPanel AJAX Control for ASP.NET 這也是一個ASP.NET的控制項，但是提供了用戶端回調(進階回調)、用戶端調用頁面方法，以及雙向兩路的序列化功能。

　　wwHoverPanel 吸取了MagicAjax.NET 和 Anthem.NET的優點，同時又結合了ASP.NET的用戶端回調功能，是一個輕量級的Ajax組件。

　　看待wwHoverPanel 最大的兩個特性中的一個是用很簡單的方式實現了一個HoverPanel Behavior，這個實現比目前Atalas的Behavior 要簡單，作者Rick Strahl 也強調這個主要是結合他具體的應用，比如這裡提供了一個小的HTML板，可以顯示獲得的結果資訊。

　　wwHoverPanel 也提供一個局部回調的方法，但是這點的實現上和MagicAjax.NET 以及 Anthem.NET完全不同，它是使用一個StartCallback的Javascript來組合查詢字串提交並且使用XMLHTTP發請求到伺服器的某個頁面(由ServerUrl 屬性指定)，之後這個頁面將結果以Response.Write()的原生HTML內容返回。這個和ASP.NET的回調方法非常類似，而且還支援將請求發到本頁之外的ASP.NET並獲得結果，所以它增強了原來ASP.NET的用戶端回調的方法，即支援其它頁面的回調。可以說，這是一種基於URL的用戶端回調。

　　wwHoverPanel 提供的第二個功能是，用戶端可以調用伺服器端中的某個頁面的方法(這些方法以[CallbackMethod]進行標識)，這種情況下，你要設定EventHandlerMode="CallPageMethod" ，然後使用wwHoverPanel.伺服器方法名(參數，參數，...，回調處理函數)的方式進行調用。這個其實使用的是一個Javascript的CallMethod 方法，調用伺服器端的請求。Javascript 的HandleCallback 則用來處理返回的結果，邏輯相對簡單，儘管控制項的innerHTML 也被賦值，但這個主要是為了維護作為用戶端回調結果顯示的小的HTML板的內容，否則就是調用頁面中的方法了，那麼結果就直接給用戶端的回調方法了。

　　特色三，就是我說的雙路的序列化功能了，其實這個情境我們也非常需要，比如我們用用戶端回調或XMLHTTP請求獲得了一個定單對象，那麼用戶端修改之後，我還想把它作為一個用戶端調用的輸入參數，返回到伺服器端。這時候兩路雙向的序列化就需要了，因為這次伺服器需要將Javascript的函數傳了的資料序列化成.NET的類。這也就是JSON的雙向序列化了(主要代碼在JSONSerializer.cs )，這也是我挺喜歡的一個功能，因為我對這個功能關注很久，但是目前流行的Ajax-NET的架構都不支援這個功能。

　　2. Anthem.NET

　　目前是1.0版本，其設計理念是通過另外一個思路，遵循這樣的理念--既然ASP.NET的各個標準控制項沒有實現提交功能，那麼我可以產生一個提交的介面，然後繼承原來的標準控制項，然後再實現這個介面，這樣每個控制項都可以向伺服器端單獨進行提交。

　　每個控制項的發生過程類似MagicAjax.NET，Anthem.NET提供了各個控制項Javascript端的提交函數-這等於也截取了__doPostBack，之後Anthem.NET 還提供了完善的用戶端的事件比如PostCallBack 和PreCallBack 這樣的用戶端事件，之後也將使用XMLHttpRequest 類比一個傳統的頁面提交請求到伺服器端，伺服器端產生頁面執行個體，這個過程和MagicAjax.NET一樣，最後是將Rendered的HTML在控制項的Render() 事件傳回到用戶端，用戶端控制項的innerHTML被賦值，動態更新。

　　和MagicAjax.NET不同的是，Anthem.NET沒有容器的概念，因為每個控制項都增加了提交介面，所以可以單獨的提交，所以單位是以一個控制項為單位進行一次提交，Anthem.NET的花費更小些(但伺服器端是類似的，因為整個ASP.NET頁面的Pipeline都會進行)。

　　此外，Anthem.NET 還有另外的功能，就是可以通過用戶端調用頁面中的方法並獲得結果/資料，這種情況下，你將調用Anthem_InvokePageMethod 方法，而不是Anthem.NET提供的預設各個控制項的提交方法。這樣Javascript的回調處理函數中的result.value 將可以獲得調用的服務端的某個方法(該方法以[Anthem.Method]為標記)的執行結果，因為JavascriptPost的資料中有Page/MasterPage/Control 了，那麼伺服器端很容易通過這個標識獲得方法的地址，應用反射尋找[Anthem.Method]標記，然後調用，將結果返回到用戶端。

　　Anthem.NET支援返回對象，DataSet，DataTable和 WriteDataRow(WriteDataSet,WriteDataTable,WriteDataRow,WriteObject)，返回的是符合是JSON規範的字串，這樣用戶端的Javascript就可以使用這些對象了。不同於MagicAjax.NET，Anthem.NET 沒有使用HTTP Model，所以結果是在頁面的PreRender() 事件中處理和返回請求的結果。

　　目前在wwHoverPanel 的情境中，我認為這是一種輕量級的實現，對於多層嵌套多組引用的對象圖類型或是大規模容量訪問壓力下，用戶端和伺服器端都還需要最佳化，所以如果其作為Ajax架構，用戶端和伺服器端通訊和傳遞資料的通訊層上，顯然是有些單薄了。

　　wwHoverPanel 的一些不足和想法:

• 　　1) 該控制項是目前我見過.NET平台下，惟一同時支援用戶端回調和頁面方法調用的Ajax 控制項，同時又支援兩路雙向的序列化。
• 　　2) 相對來說，wwHoverPanel是設計最簡單的一個，而且是基於控制項不依賴HTTP Model和ASP.NET Page Pipeline，也不依賴ViewState
• 　　3) 該控制項能夠讓你在Ajax特性實現的技術層面上，能夠在客戶回調和用戶端調用頁面方法兩者中取得平衡。
• 　　4) 目前的用戶端回調支援其它頁面的回調，但是其結果輸出需要輸出原始的HTML，這個影響應用的分層和設計。
• 　　5) JSON的雙向序列化是一個不錯的方案，但高效能的情境下，應該考慮實現更高效的序列化架構

　　4. Atlas

　　這個產品，我就不列舉具體的功能了，而主要說一下我對其的看法和持有的態度。因為在我的Ajax書評中提到過問題。

　　Atlas 是一個個性鮮明的產品，其優點是明顯的，缺點也是明顯的，但首先你必須認識到它還是一個比較複雜，擁有較高學習曲線的解決方案。對於其複雜性，老實說目前，大多數人還缺乏真實的感受。

　　最近的一個個版本-Jan CTP，我們看到了一些特性，其強大之處在於:

• 　　1.用戶端(Javascript)的資料繫結、校正帶來便利。
• 　　2. 新的Update Panels不僅擁有了MagicAjax.NET 的特性，而且功能更強，是目前Atlas中非同步回調的主要控制項。
• 　　3.內建了一些具體Ajax特性的控制項，比如AutoCompleteExtender ，DragOverlayExtender
• 　　4. 提供了一些使用的控制項比如，ScriptManager, Triggers ,TimerControl
• 　　5. 主要用途著重在提供一個用戶端控制項和伺服器端控制項的特性整合的方案和容易使用的開發效率上。

　　但缺點也是明顯的，比如:

• 　　1. 用戶端的Behaviors還很弱，模板(Templates)和UI增強(UI Enhancements)功能還沒有看到。
• 　　2. 所謂的用戶端Atlas控制項(“Atlas” Client Controls)和伺服器端的Atlas控制項(“Atlas” Server Controls) 還沒有一個明確的規範，所以現在你基本上還不能建立自訂的Atlas控制項(無論用戶端還是伺服器端的)。
• 　　3. 目前還只支援調用Web Services的服務，對於ASP.NET的內建的服務以及WCF的服務支援也沒有看見，也不支援頁面或控制項內的方法調用
• 　　4. 功能上還不穩定，一些功能僅是在特定條件下的特性實現，還不能滿足部署生產環境的要求。我認為，如果Atlas發布Go-Live License，那麼可以考慮Atlas的放入到正式的項目或應用中。

　　我並不建議，你現在就將它應用在一個老的ASP.NET 項目中，或是老項目遷移到ASP.NET v2.0時優先考慮它;更多時候，如果你是建立一個新的ASP.NET應用，而又跨越了其學習曲線的情況下，可以考慮使用它。目前的情況下，對於Atlas，我建議，你應該保持足夠的關注和實踐學習，但是要抑制住將其應用到項目中的興趣;因為Ajax，你現在可以開始關注和學習它，但是你不能因為要實現Ajax一個特性，而立即選擇Atlas，那麼是可能有風險的。