ajax总体概述
????? "似Ajax" 這就是說，你的應(yīng)用程序是在Ajax概念提出之前就創(chuàng)建的。從客戶端和服務(wù)器端的交互分析來說，你的客戶端有大量的Javascript 代碼接受XML數(shù)據(jù)，進(jìn)行對象的序列化，然后使用Javascript配合其它的HTML技術(shù)展現(xiàn)這些對象和數(shù)據(jù)，也可能你還有一堆HTC或其它的Javascript的HTML表現(xiàn)層控件。你的服務(wù)器端是一個Facade(或者是Adapter,Observer)模式的(Handler)控制器，接收客戶端Javascript的XML請求數(shù)據(jù)后，然后解析XML，然后調(diào)用相應(yīng)的某個服務(wù)或業(yè)務(wù)組件，再將結(jié)果以XML的形式返回給客戶端Javascript ，客戶端的Javascript接收之后，再進(jìn)行處理和顯示，因為可以使用HTML的DOM 和CSS，所有頁面的展現(xiàn)是動態(tài)的。
這樣客戶端是<Ajax in Action>中描述的Script-centric architecture 或Data-centric interactions 的方式。而且這種方式和Jesse James Garrett列舉的Ajax 是最類似的，只不過那時你或我不知道這個可以叫Ajax，只不過是現(xiàn)在的人誤解了Ajax，Ajax成了一種技術(shù)，一種特性，而首先不是一種某種架構(gòu)下Web 應(yīng)用了。
?
目前流行的Ajax-NET的框架基本上都沒有實現(xiàn)雙向序列化，因為實現(xiàn)一個TextBox的自動完成客戶端只用接收數(shù)據(jù)就行了，根本不用傳回數(shù)據(jù)/對象到服務(wù)器端，同樣做一個Ajax的狀態(tài)進(jìn)度條也不用，但這些都是Ajax啊，我們衡量的標(biāo)準(zhǔn)是異步的、頁面沒有刷新。
?
1.????? MagicAjax.NET
這是目前框架中版本號最小的一個Ajax-NET實現(xiàn)，許多人很喜歡它，甚至一見如故，但真的看過它的代碼之后，我有些擔(dān)憂。
MagicAjax.NET基于這樣一種策略，即__doPostBack 會提及整個的ASP.NET頁面，這樣會導(dǎo)致頁面刷新，所以MagicAjax.NET使用AJAXCbo.DoPostCallBack 做局部的提交，而每個Ajax
Panel 中的內(nèi)容則對應(yīng)客戶端即時的HTML內(nèi)容，因為在MagicAjax.NET中，客戶端只用執(zhí)行eval(responseText) 服務(wù)器端Rendered返回的HTML就可以了(很被動)。
由于DoPostCallBack 會提交ViewState 以及AjaxPanelx$RBS_Store，幾乎是用XMLHttpRequest 模擬一個正常的提交，所以服務(wù)器端可以創(chuàng)建頁面的實例也可以根據(jù)ViewState 恢復(fù)所有的控件狀態(tài)，同樣AjaxPanel 以及AjaxControl 也都會實例化，然后接收客戶端傳來的_EventTarget, _EventArgument 走正常的ASP.NET控件的處理過程，等控件Rendered之后，最終的HTML輸出被傳回客戶端，然后被客戶端的eval 顯示出來。
整個過程非常巧妙，這幾乎是ASP.NET __doPostBack 的"Hook ASP.NET"版和加強(qiáng)版本。
而HttpModel 主要是為了解決Session和交叉提交，進(jìn)行客戶端Javascript的整理和注入，當(dāng)然也是這里接收客戶端的請求，在Application_EndRequest中返回結(jié)果。剩下的代碼都是處理控件在VS Web Design中的設(shè)計時支持。AjaxCallObject.js 和WebParts.js 每次都要傳到客戶端。
MagicAjax.NET 的一些不足和想法：
1。 __doPostBack 的加強(qiáng)版，適合于ASP.NET的高級用戶使用
2。由于和ASP.NET的頁面處理機(jī)制依賴非常密切，控件的默認(rèn)動作發(fā)生變化則可能不工作，比如第三方的某個自定義控件；
3。依賴ViewState ，如果是加密的ViewState，則可能工作不正常，我沒有試，在代碼中好像沒有看見__VIEWSTATEENCRYPTED
4。是對ASP.NET 全部頁面提交的優(yōu)化，實現(xiàn)有限的Ajax功能，可擴(kuò)展性不大
如果是基于ASP.NET 提供的控件和開發(fā)，那么MagicAjax.NET 是非常有效的，很好的解決了Session和跨頁面狀態(tài)的問題。而且客戶端的操作和工作基本可以忽略，MagicAjax.NET設(shè)計貼近最近的ASP.NET的版本，目前不提供調(diào)用客戶端直接調(diào)用頁面的方法。但隨著其發(fā)展，優(yōu)勢可能漸少，因為Atlas 最新的版本提供類似的UpdatePanel 控件。
?
2. Anthem.NET
目前是1.0版本，其設(shè)計理念是通過另外一個思路，遵循這樣的理念--既然ASP.NET的各個標(biāo)準(zhǔn)控件沒有實現(xiàn)提交功能，那么我可以產(chǎn)生一個提交的接口，然后繼承原來的標(biāo)準(zhǔn)控件，然后再實現(xiàn)這個接口，這樣每個控件都可以向服務(wù)器端單獨進(jìn)行提交。
每個控件的發(fā)生過程類似MagicAjax.NET，Anthem.NET提供了各個控件Javascript端的提交函數(shù)－這等于也截取了__doPostBack，之后Anthem.NET 還提供了完善的客戶端的事件比如PostCallBack 和PreCallBack 這樣的客戶端事件，之后也將使用XMLHttpRequest 模擬一個傳統(tǒng)的頁面提交請求到服務(wù)器端，服務(wù)器端生成頁面實例，這個過程和MagicAjax.NET一樣，最后是將Rendered的HTML在控件的Render() 事件傳回到客戶端，客戶端控件的innerHTML被賦值，動態(tài)更新
和MagicAjax.NET不同的是，Anthem.NET沒有容器的概念，因為每個控件都增加了提交接口，所以可以單獨的提交，所以單位是以一個控件為單位進(jìn)行一次提交，Anthem.NET的花費更小些(但服務(wù)器端是類似的，因為整個ASP.NET頁面的Pipeline都會進(jìn)行)。
此外，Anthem.NET 還有另外的功能，就是可以通過客戶端調(diào)用頁面中的方法并獲得結(jié)果/數(shù)據(jù)，這種情況下，你將調(diào)用Anthem_InvokePageMethod 方法，而不是Anthem.NET提供的默認(rèn)各個控件的提交方法。這樣Javascript的回調(diào)處理函數(shù)中的result.value 將可以獲得調(diào)用的服務(wù)端的某個方法(該方法以[Anthem.Method]為標(biāo)記)的執(zhí)行結(jié)果，因為JavascriptPost的數(shù)據(jù)中有Page/MasterPage/Control 了，那么服務(wù)器端很容易通過這個標(biāo)識獲得方法的地址，應(yīng)用反射尋找[Anthem.Method]標(biāo)記，然后調(diào)用，將結(jié)果返回到客戶端。
Anthem.NET支持返回對象，DataSet，DataTable和 WriteDataRow(WriteDataSet,WriteDataTable,WriteDataRow,WriteObject)，返回的是符合是JSON規(guī)范的字符串，這樣客戶端的Javascript就可以使用這些對象了。不同于MagicAjax.NET，Anthem.NET 沒有使用HTTP Model，所以結(jié)果是在頁面的PreRender() 事件中處理和返回請求的結(jié)果。
2.1 Ajax.NET Professional
我沒有看過Ajax.NET Professional 的源代碼，但從例子中看得其支持調(diào)用頁面的某個方法，以及返回對象，DataSet，DataTable的數(shù)據(jù)，我認(rèn)為Ajax.NET Professional 的實現(xiàn)和Anthem.NET 原理是一樣的，雖然Ajax.NET Professional 使用了HTTP Model，這個只是和Anthem.NET 一樣，最終處理結(jié)果的返回處理上稍有不同不同。比較起來，Ajax.NET Professional 沒有重新繼承所有常用的ASP.NET控件實現(xiàn)部分提交的功能，所以可能Ajax.NET Professional 比較強(qiáng)項的是調(diào)用頁面上的某個方法，并在客戶端獲得結(jié)果的數(shù)據(jù)，這個已經(jīng)夠?qū)崿F(xiàn)大部分的Ajax的功能了。
從這個層面上看，我認(rèn)為Ajax.NET Professional 是相對笨重和復(fù)雜了。Anthem.NET不使用HTTP Model，提供控件基本的局部提交，也提供數(shù)據(jù)層面的客戶端方法調(diào)用。Ajax.NET Professional 的源代碼似乎總是不想共享 ，這也是我不喜歡它的另外一個原因。
無論如何，大家都沒有提供兩路的數(shù)據(jù)交換，即客戶端可以獲得服務(wù)器端的方法并獲得結(jié)果和數(shù)據(jù)，但是目前都支持將這些對象/數(shù)據(jù)修改之后返回給服務(wù)器端。
Anthem.NET 的一些不足和想法：
1. Anthem.NET 也是一種"Hook ASP.NET"原理，旨在彌補(bǔ)ASP.NET的整頁面的提交和PostBack，并且在客戶端的數(shù)據(jù)訪問和交互上做了加強(qiáng)。
2. Anthem.NET需要重新將ASP.NET提供的控件進(jìn)行繼承和包裝，所以使用和功能的兼容性上非常敏感。
3. 也許微軟下個版本的ASP.NET的標(biāo)準(zhǔn)控件可以借鑒Anthem.NET的做法，給各個控件增加這個遠(yuǎn)程回調(diào)的接口。
4. 目前版本的功能已經(jīng)非常強(qiáng)大和略有些復(fù)雜了，而且部署比較方便，無需設(shè)置HTTP Model。
經(jīng)典必看文章-Introduction to Anthem.NET
http://www.codeproject.com/useritems/AnthemNET.asp#xxxx
3. wwHoverPanel AJAX Control for ASP.NET
wwHoverPanel AJAX Control for ASP.NET 這也是一個ASP.NET的控件，但是提供了客戶端回調(diào)(高級回調(diào))、客戶端調(diào)用頁面方法，以及雙向兩路的序列化功能。
wwHoverPanel 吸取了MagicAjax.NET 和 Anthem.NET的優(yōu)點，同時又結(jié)合了ASP.NET的客戶端回調(diào)功能，是一個輕量級的Ajax組件。
看待wwHoverPanel 最大的兩個特性中的一個是用很簡單的方式實現(xiàn)了一個HoverPanel Behavior，這個實現(xiàn)比目前Atalas的Behavior 要簡單，作者Rick Strahl 也強(qiáng)調(diào)這個主要是結(jié)合他具體的應(yīng)用，比如這里提供了一個小的HTML板，可以顯示獲得的結(jié)果信息。
wwHoverPanel 也提供一個局部回調(diào)的方法，但是這點的實現(xiàn)上和MagicAjax.NET 以及 Anthem.NET完全不同，它是使用一個StartCallback的Javascript來組合查詢字符串提交并且使用XMLHTTP發(fā)請求到服務(wù)器的某個頁面(由ServerUrl 屬性指定)，之后這個頁面將結(jié)果以Response.Write()的原生HTML內(nèi)容返回。這個和ASP.NET的回調(diào)方法非常類似，而且還支持將請求發(fā)到本頁之外的ASP.NET并獲得結(jié)果，所以它增強(qiáng)了原來ASP.NET的客戶端回調(diào)的方法，即支持其它頁面的回調(diào)。可以說，這是一種基于URL的客戶端回調(diào)。
wwHoverPanel 提供的第二個功能是，客戶端可以調(diào)用服務(wù)器端中的某個頁面的方法(這些方法以[CallbackMethod]進(jìn)行標(biāo)識)，這種情況下，你要設(shè)置EventHandlerMode="CallPageMethod" ，然后使用wwHoverPanel.服務(wù)器方法名(參數(shù)，參數(shù)，...，回調(diào)處理函數(shù))的方式進(jìn)行調(diào)用。這個其實使用的是一個Javascript的CallMethod 方法，調(diào)用服務(wù)器端的請求。Javascript 的HandleCallback 則用來處理返回的結(jié)果，邏輯相對簡單，盡管控件的innerHTML 也被賦值，但這個主要是為了維護(hù)作為客戶端回調(diào)結(jié)果顯示的小的HTML板的內(nèi)容，否則就是調(diào)用頁面中的方法了，那么結(jié)果就直接給客戶端的回調(diào)方法了。
特色三，就是我說的雙路的序列化功能了，其實這個場景我們也非常需要，比如我們用客戶端回調(diào)或XMLHTTP請求獲得了一個定單對象，那么客戶端修改之后，我還想把它作為一個客戶端調(diào)用的輸入?yún)?shù)，返回到服務(wù)器端。這時候兩路雙向的序列化就需要了，因為這次服務(wù)器需要將Javascript的函數(shù)傳了的數(shù)據(jù)序列化成.NET的類。這也就是JSON的雙向序列化了(主要代碼在JSONSerializer.cs )，這也是我挺喜歡的一個功能，因為我對這個功能關(guān)注很久，但是目前流行的Ajax-NET的框架都不支持這個功能。
目前在wwHoverPanel 的場景中，我認(rèn)為這是一種輕量級的實現(xiàn)，對于多層嵌套多組引用的對象圖類型或是大規(guī)模容量訪問壓力下，客戶端和服務(wù)器端都還需要優(yōu)化，所以如果其作為Ajax架構(gòu)，客戶端和服務(wù)器端通信和傳遞數(shù)據(jù)的通訊層上，顯然是有些單薄了。
wwHoverPanel 的一些不足和想法：
1. 該控件是目前我見過.NET平臺下，惟一同時支持客戶端回調(diào)和頁面方法調(diào)用的Ajax 控件，同時又支持兩路雙向的序列化。
2. 相對來說，wwHoverPanel是設(shè)計最簡單的一個，而且是基于控件不依賴HTTP Model和ASP.NET Page Pipeline，也不依賴ViewState
3. 該控件能夠讓你在Ajax特性實現(xiàn)的技術(shù)層面上，能夠在客戶回調(diào)和客戶端調(diào)用頁面方法兩者中取得平衡。
4. 目前的客戶端回調(diào)支持其它頁面的回調(diào)，但是其結(jié)果輸出需要輸出原始的HTML，這個影響應(yīng)用的分層和設(shè)計。
5. JSON的雙向序列化是一個不錯的方案，但高性能的場景下，應(yīng)該考慮實現(xiàn)更高效的序列化框架
經(jīng)典必看文章-wwHoverPanel AJAX Control for ASP.NET posted
http://west-wind.com/weblog/posts/4408.aspx
4. Atlas
這個產(chǎn)品，我就不列舉具體的功能了，而主要說一下我對其的看法和持有的態(tài)度。因為在我的Ajax書評中提到過問題。
Atlas 是一個個性鮮明的產(chǎn)品，其優(yōu)點是明顯的，缺點也是明顯的，但首先你必須認(rèn)識到它還是一個比較復(fù)雜，擁有較高學(xué)習(xí)曲線的解決方案。對于其復(fù)雜性，老實說目前，大多數(shù)人還缺乏真實的感受。
最近的一個個版本-Jan CTP，我們看到了一些特性，其強(qiáng)大之處在于：
1.客戶端(Javascript)的數(shù)據(jù)綁定、校驗帶來便利。
2. 新的Update Panels不僅擁有了MagicAjax.NET 的特性，而且功能更強(qiáng)，是目前Atlas中異步回調(diào)的主要控件。
3.內(nèi)置了一些具體Ajax特性的控件，比如AutoCompleteExtender ，DragOverlayExtender
4. 提供了一些使用的控件比如，ScriptManager, Triggers ,TimerControl
5. 主要用途著重在提供一個客戶端控件和服務(wù)器端控件的特性集成的方案和容易使用的開發(fā)效率上。
但缺點也是明顯的，比如：
1. 客戶端的Behaviors還很弱，模板(Templates)和UI增強(qiáng)(UI Enhancements)功能還沒有看到。
2. 所謂的客戶端Atlas控件(“Atlas” Client Controls)和服務(wù)器端的Atlas控件(“Atlas” Server Controls) 還沒有一個明確的規(guī)范，所以現(xiàn)在你基本上還不能創(chuàng)建自定義的Atlas控件(無論客戶端還是服務(wù)器端的)。
3. 目前還只支持調(diào)用Web Services的服務(wù)，對于ASP.NET的內(nèi)置的服務(wù)以及WCF的服務(wù)支持也沒有看見，也不支持頁面或控件內(nèi)的方法調(diào)用
4. 功能上還不穩(wěn)定，一些功能僅是在特定條件下的特性實現(xiàn)，還不能滿足部署生產(chǎn)環(huán)境的要求。我認(rèn)為，如果Atlas發(fā)布Go-Live License，那么可以考慮Atlas的放入到正式的項目或應(yīng)用中。
我并不建議，你現(xiàn)在就將它應(yīng)用在一個老的ASP.NET 項目中，或是老項目遷移到ASP.NET v2.0時優(yōu)先考慮它；更多時候，如果你是創(chuàng)建一個新的ASP.NET應(yīng)用，而又跨越了其學(xué)習(xí)曲線的情況下，可以考慮使用它。目前的情況下，對于Atlas，我建議，你應(yīng)該保持足夠的關(guān)注和實踐學(xué)習(xí)，但是要抑制住將其應(yīng)用到項目中的興趣；因為Ajax，你現(xiàn)在可以開始關(guān)注和學(xué)習(xí)它，但是你不能因為要實現(xiàn)Ajax一個特性，而立即選擇Atlas，那么是可能有風(fēng)險的。
注： Atals 的Microsoft.Web.Script.Serialization 命名空間中有JavaScriptObjectDeserializer和JavaScriptObjectSerializer兩個對象，第一，我不確定其是否也是JSON 序列化，而且我也不確定目前是否支持兩路雙向的序列化；第二，目前的版本，我還不能進(jìn)行自定義或擴(kuò)展，同時也很難對于其性能做任何的結(jié)論。
經(jīng)典必看文章- Atlas 快速學(xué)習(xí)參考
http://atlas.asp.net/quickstart/default.aspx
基于Ajax 架構(gòu)的Web應(yīng)用框架
之前我提到過"似Ajax" 的架構(gòu)，現(xiàn)在我要說的Ajax框架也就是指專門針對這種Ajax架構(gòu)而提供的框架。目前，我還沒有聽說過特別好的這個領(lǐng)域的流行框架。但我知道我的身邊，.NET領(lǐng)域，J2EE領(lǐng)域或PHP平臺上都有這樣的框架和應(yīng)用，我認(rèn)為，正是因為有很多這樣應(yīng)用，所以Ajax才會像某個模式一樣，被撰有一個專門的名詞。不過我感覺Ajax 漸漸變成了Ajax feature的代名詞，變成了XMLHTTP的代名詞，成了異步通訊，不刷新頁面的技術(shù)表示法。直到我看過Ajax in Action這本書，我才把Ajax和系統(tǒng)的架構(gòu)、設(shè)計模式，分布式對象的序列化和我之前的項目和經(jīng)歷聯(lián)系在一切。
我修改了一些Jesse的圖，來說明我認(rèn)為的基于Ajax的架構(gòu)是什么樣的。
這也就是我上面說的“似Ajax”架構(gòu)，首先它是一個Web應(yīng)用；它的表現(xiàn)層用DHTML＋CSS ＋ HTC控件＋ Javascript ，服務(wù)器端用.NET或任何的服務(wù)器端技術(shù)，中間以XML方式序列化和反序列化進(jìn)行傳遞數(shù)據(jù)。
簡單的說，客戶端需要將請求的數(shù)據(jù)封裝成一個XML數(shù)據(jù)通過HTTP傳遞給服務(wù)器端，服務(wù)器端處理這個請求，并將結(jié)果也以XML的形式返回到客戶端，客戶端再處理這些請求，然后使用HTML+CSS進(jìn)行展示。其實如果不是Web客戶端(瀏覽器)的問題，這是最簡單的架構(gòu)，但關(guān)鍵問題在于上面我們說的Javascript端的對象封裝成一個XML，以及到服務(wù)端解析XML變成服務(wù)器端對象，然后再將結(jié)果封裝成XML，傳回給客戶端(Javascript)，客戶端也解析XML數(shù)據(jù)，然后變成Javascript 中的對象的這個序列化和反序列化的問題。另外一個問題就是表現(xiàn)層的展現(xiàn)問題，怎么展現(xiàn)，用什么控件？
所以，一個Ajax架構(gòu)的Web應(yīng)用程序，必須解決下面的問題：
1. 雙向兩路的序列化問題
2. 表現(xiàn)層展現(xiàn)的問題
3. 傳輸時客戶端和服務(wù)器端的數(shù)據(jù)安全問題
4. 性能問題
5. 國際化支持
最好玩的雙向兩路的序列化問題，最早接觸的是JSON ，它的問題在于擴(kuò)展性，數(shù)據(jù)類型的支持和性能，但是平臺無關(guān)性比較好，什么瀏覽器都可以，因為它不需要用msxml2.DOMDocumen分析XML，本質(zhì)上就是用字符串描述對象；之后多平臺的應(yīng)用的遷移經(jīng)歷中(比如CORBAR，J2EE的后臺應(yīng)用)，開始接觸到XML-RPC ，ICE，Hessian，Web Services等等。其中XML-RPC有Javascript 的支持庫，Web Services也有Javascript的支持庫，也就是你可以使用Javascript訪問或者獲得XML－RPC/Web Services的對象，但是如果你將其作為一個主要的通訊協(xié)議，那么就會遇到另外一些問題，比如性能、國際化的問題，又會困擾你，XML-RPC和Web Services的一個主要問題都是性能，因為他們傳輸?shù)?/span>XML大小都太大了，但顯然用這些實現(xiàn)一個Ajax的特性，那是完全沒有問題了。
比如，Atlas目前不也是使用一個Javascript庫調(diào)用Web Services嗎？，所以，你也可以這么做，同樣你也可以用XML-RPC.NET 很快就可以實現(xiàn)一個Service，然后使用Scotandrew的XML-RPC javascript 庫就可以在Javascript中發(fā)一個XML-RPC 消息請求這個服務(wù)，然后異步的獲得這個結(jié)果，然后展現(xiàn)它。所以從技術(shù)的實現(xiàn)上講，Ajax的特性非常容易實現(xiàn)，但從架構(gòu)上來看。你需要思考更多的因素。當(dāng)然直到最后，我們才發(fā)現(xiàn)，在項目中，最完美的方案是你自己寫一個雙向兩路的序列化引擎供你的Javascript客戶端使用。
這就說到了第二個問題，界面表現(xiàn)的問題，這個問題也是一個大的問題。這個問題一直會永遠(yuǎn)存在，Ajax之前沒有人會太注意這些，但今天不同了，我想未來還會有很大的一個飛躍， Yahoo! 不是最近也開源了他的Yahoo! Web UI庫，Atlas 也表示要提供更多的前端UI控件。無論如何，這個問題是，你的團(tuán)隊或組織是否有一套經(jīng)過項目或客戶檢驗的前端Javascript的庫。無論是自己用Javascript寫的也好，是自己寫的一套HTC的控件庫也好，總之這些是Ajax 架構(gòu)中非常重要的一環(huán)。
Atlas 帶來了另外一個思考問題，就是服務(wù)器端控件可能可以通過某種方式和Javascript的控件很好的集成在一起，以前我們用HTC解決了重用、性能、Behaviors、甚至模板功能。但是新的特性還是有比如數(shù)據(jù)的綁定、緩存和校驗、甚至是數(shù)據(jù)編碼和壓縮、加密和解密，Javascript UI前端還是有許多可以做的，而且如何無縫的集成兩者，這個有非常大的意義。
接著安全、性能、國際化等等，架構(gòu)中的問題需要你依次考慮和解決，如果這么看Ajax，我認(rèn)為，目前的Ajax框架還有很長很長一段路要走，同樣真正完美支持Ajax架構(gòu)的還需要繼續(xù)努力。這些也是我在這篇專欄文章中的觀點。
把這些合在一起，那么Ajax架構(gòu)的開發(fā)包或框架，就應(yīng)該是包含了上述幾個問題(兩路雙向的序列化、Javascript UI 表現(xiàn)庫、安全、國際化和性能等等)解決方案的一個平臺實現(xiàn)。
同樣也許你會說，不就是Ajax嗎? 我干嘛要搞這么復(fù)雜，一定要搞到架構(gòu)這個層面。
我認(rèn)為，
第一，從架構(gòu)的層面看Ajax，然后再應(yīng)用相關(guān)的技術(shù)，比你直接使用某個Ajax框架然后再理解Ajax，你會從這個過程中收獲更多。
第二，對于一個開發(fā)團(tuán)隊/組織來說，真正Ajax架構(gòu)的產(chǎn)品，可以帶來效益和具體的生產(chǎn)力。比如，我身邊就有擁有這樣的優(yōu)勢的團(tuán)隊，他們擁有一套統(tǒng)一的由Javascript+HTML+CSS+HTC的前端表現(xiàn)層，而后臺的業(yè)務(wù)系統(tǒng)有兩個平臺，一個.NET平臺和J2EE平臺；同樣我身邊的也有這樣的團(tuán)隊，他們擁有一套統(tǒng)一的由Javascript+DHTML+CSS+HTC＋VML+ASP.NET的前端表現(xiàn)層，但他們的后臺業(yè)務(wù)層分別來自.NET平臺、J2EE平臺和Unix平臺，我不能說Ajax架構(gòu)的應(yīng)用似乎就是統(tǒng)一Web 表現(xiàn)層。因為從今天看到他們的明天，也許會是, 一個ASP.NET V2+Atlas 的統(tǒng)一表現(xiàn)層，一個統(tǒng)一CAB+Smart Client 的統(tǒng)一表現(xiàn)層，也可以是一個WPF 3D的統(tǒng)一表現(xiàn)層，也可以是一個Xgl 桌面的統(tǒng)一層。。。。
第三，從這架構(gòu)的層面上，你也能夠非常容易理解SOA或ESB概念，和SOA相比，Ajax架構(gòu)的區(qū)別在于，Ajax有足夠的松散耦合，但它依然以應(yīng)用的數(shù)據(jù)為中心，更多的是一個面向Messages的架構(gòu)，而且對于流行的WS-*協(xié)議的支持非常有限。
但是假如，今天你或你的團(tuán)隊已經(jīng)有了一個Ajax 架構(gòu)的應(yīng)用，那么你是不是應(yīng)該要小心選擇現(xiàn)有的Ajax框架，因為這些Ajax的特性，相對于目前的架構(gòu)來說，是多么小，但又可能會產(chǎn)生很大危害的一個因素。也許這樣的團(tuán)隊并不多，也許也很多，但是只有我們從更高更深的層次來思考，那么我們就能做出正確的選擇，并且從新的Ajax技術(shù)和研究中獲得好處。
結(jié)論
當(dāng)我們回到文章的起點，我希望這樣能夠說明的我觀點，即Ajax-NET的框架或?qū)崿F(xiàn)分為兩類，一類是基于Ajax應(yīng)用程序架構(gòu)的，一類是基于Ajax特性的，目前幾乎大部分的Ajax-NET的框架或?qū)崿F(xiàn)都是基于Ajax特性，以Add-in 方式提供的代碼或框架。
Ajax-NET的實現(xiàn)/框架選取上的建議：
·???????? ASP.NET控件形式已經(jīng)成為連接服務(wù)器和客戶端Ajax通信的主要形式和選擇。
·???????? 客戶端調(diào)用服務(wù)器端頁面中的方法是Ajax的重要手段，使得客戶端可以更加靈活的獲得服務(wù)器端的數(shù)據(jù)。
·???????? MagicAjax.NET，Anthem.NET用了"Hook ASP.NET"和Add－In的技術(shù)手段，使用上受到的影響比較多，這兩個框架中，最簡單的應(yīng)用，第一選擇MagicAjax.NET，但總是優(yōu)先使用Anthem.NET
·???????? 如果是自己寫的服務(wù)器端控件，那么應(yīng)該先掌握Anthem.NET的技術(shù)，然后使自己的控件擁有Ajax的特性
·???????? MagicAjax.NET, Anthem.NET和wwHoverPanel 對于國際化的支持都有待加強(qiáng)
·???????? 在Atlas沒有正式發(fā)布之前，在ASP.NET的應(yīng)用中優(yōu)先在自己的項目中使用類似wwHoverPanel的技術(shù)，即盡可能的使用客戶端回調(diào)功能，在特別需要的地方使用其方法調(diào)用的功能，充分發(fā)揮Ajax的特性，而不要因為Ajax而特意選擇某個Ajax的框架
·???????? Atlas的強(qiáng)項在于服務(wù)器端和客戶端控件特性的集成、客戶端的數(shù)據(jù)綁定、校驗、內(nèi)置的多個客戶端Ajax 特性UI或組件，與ASP.NET的Profile, Membership ,Role 服務(wù)的集成，與Web Services和WCF 服務(wù)的集成，以及良好的國際化/開發(fā)工具支持的。因為它是一個完整的解決方案，所以最大的弱點是不能很容易地被老的Ajax架構(gòu)的應(yīng)用使用。另外該產(chǎn)品目前還在不斷開發(fā)中，距離部署到生產(chǎn)環(huán)境中的要求還有差距。
·???????? 輕量級的雙向序列化可以考慮JSON格式，安全問題可以在傳遞的對象中增加字段，然后在服務(wù)器端進(jìn)行校驗。
·???????? 對于原來已經(jīng)有一套序列化框架的組織來說，其主要的目標(biāo)是盡快將這個框架遷移/升級到ASP.NET V2，而不是優(yōu)先考慮實現(xiàn)某個Ajax的特性
·???????? Ajax 要求有足夠的力量關(guān)注前端的UI展現(xiàn)或開發(fā)，所以對Ajax實現(xiàn)/框架的選擇，最先要考察其客戶端的實現(xiàn)以及提供的Web UI
看完這篇文章，我希望，2006年我們再談起Ajax的時候，
·???????? 作為技術(shù)人員，我不用談?wù)撌裁?/span>Web 2.0，我一樣可以清楚的表達(dá)Ajax的概念
·???????? 如果你是一個架構(gòu)師，Ajax 不再是什么異步的XMLHTTP調(diào)用，不再是不刷新頁面，它可以幫忙你Review應(yīng)用程序的架構(gòu)。
·???????? 對于你的團(tuán)隊或老板來說，Ajax可以是你統(tǒng)一界面表現(xiàn)層的一個策略，同樣也可能讓你有了一個創(chuàng)建一套部門或公司級能夠重用的UI類庫的機(jī)會。
·???????? 同樣對于Javascript的開發(fā)人員來說，Ajax讓你們還需要了解一些業(yè)務(wù)，并證明前臺的Web開發(fā)人員一樣很昂貴，后臺開發(fā)也可以是技術(shù)含量不高的
·???????? 對于SOA的愛好者來說，Ajax架構(gòu)讓你能夠站在面向消息的架構(gòu)和系統(tǒng)上來看面向服務(wù)；一般我們說，對內(nèi)你首先要有一套面向消息的架構(gòu)，然后對外你就很容易延伸成一個面向服務(wù)面向Internet的分布式架構(gòu)。
·???????? 最后，不要討論Ajax的消亡，因為Ajax對于程序員來說，是一種力量均衡的策略，在Ajax中，Web前端的開發(fā)人員被重新重視，成為一支重要的力量。
后記
寫這些文字的某幾個段落，讓我有些痛苦，因為我本來沒想些這么多。所以你不要太在意我對各個框架的評價和描述，這些都是技術(shù)的層面的東西，其實我寫這篇文字，主要是想突出Ajax的架構(gòu)觀，以及設(shè)計模式和Web應(yīng)用架構(gòu)重構(gòu)的考慮，續(xù)而你也能夠用類似橫切面的角度，用Ajax來看你目前的應(yīng)用和架構(gòu)，從而更深的了解分布式對象的序列化、性能、安全以及Ajax 和ASP.NET服務(wù)器端控件的融合。最后歡迎大家斧正。
名詞：
SOA = Service-Oriented Architectures
ESB = Enterprise Service Bus
Ajax-NET = .NET平臺下的Ajax實現(xiàn)或框架
Ajax架構(gòu) = Ajax-Oriented Architectures
HTC = HTML Components
VML = Vector Markup Language
DHTML = Dynamic HTML
WPF = Windows Presentation Foundation
WCF = Windows Communication Foundation
Xgl = Xgl graphics subsystem(Novell )
JSON =JavaScript Object Notation
CAB = Composite UI Application Block
轉(zhuǎn)載于:https://www.cnblogs.com/wsky/articles/807699.html
總結(jié)
- 上一篇： - -(我最近的开发..)
- 下一篇： 【哈利波特】Sherbert Lemon