九色国产,午夜在线视频,新黄色网址,九九色综合,天天做夜夜做久久做狠狠,天天躁夜夜躁狠狠躁2021a,久久不卡一区二区三区

　　在這里我將試圖考察一下目前.NET平臺的下的Ajax框架，我也試圖從中總結出來一種方法，使得你可以在眾多基于.NET平臺的Ajax框架和工具包中找到你所合適的一種，同時也希望你在考察、預研和使用這些流行的這些Ajax-NET的框架時，做得理性和有的放矢。
　　我想，文章的方法會給目前使用Ajax的.NET用戶帶來幫助，從而提高你在.NET平臺下使用Ajax的體驗。為什么這么說，因為最近我的一個客戶(應該是一些客戶)的研發(fā)主管對我說，我們對Atlas非常興趣，想了解更多一些相關的內容和如何開始看待Atlas，因為下個月會來一個Atlas的專家和我們交流。因為我知道這個主管手上掌握著一個Ajax架構的業(yè)務應用，目前在考慮從.NETv1.1遷移到.NETv2.0，Atlas能在怎樣的程度上幫忙他或他的Team？我沒有說太多，因為心里我有些吃驚，目前的他們的架構應用Atlas可能并不是一個明智的選擇，當然這個擔心基于我目前對Atlas的理解。
　　我列舉和討論的Ajax-NET的框架和工具包括Atlas(Jan CTP), Anthem.NET, MagicAjax.NET, Ajax.NET Professional 和wwHoverPanelControl，這基本都是我關注的.NET平臺的下的Ajax的一些框架和實現。基本上也都是我的這篇文章中列舉的，另外一個原因是因為他們基本上都是開源的，這個非常重要，因為沒有源代碼，我們將不知道究竟發(fā)生了什么。另外我無意于使之成為像DanielZeiss作的這個比較報告。
　　首先，開門見山的說明我的觀點。
　　對于開源或現有的Ajax-NET技術或框架的選用必須針對你目前應用的架構來選取和考慮，如果你目前的架構是"似Ajax"的，那么你在選擇現在所有流行的Ajax-NET的技術的時候都必須非常小心；而如果你目前的應用是使用傳統(tǒng)的ASP.NET的應用架構(或準備用ASP.NETv2.0開始創(chuàng)建新的應用)，那么目前流行的Ajax-NET的框架和技術都是普遍適合的，關鍵你要在合適的時機選擇合適的某個框架或實現。
　　在我的眼中，目前流行的Ajax-NET的框架或實現都是Add-in(Plug-in)的模式的，也就是說這些框架對于所有后一種即使用傳統(tǒng)的ASP.NET的應用架構(或準備用ASP.NETv2.0開始創(chuàng)建新的應用)是Awared的也就是非常有利和方便的。但對于"似Ajax"的架構來說，情況有所不同，需要你從另外的角度來衡量，有選擇的使用。
　　那什么是"似Ajax"的架構呢，這就是說，你的應用程序是在Ajax概念提出之前就創(chuàng)建的。從客戶端和服務器端的交互分析來說，你的客戶端有大量的Javascript代碼接受XML數據，進行對象的序列化，然后使用Javascript配合其它的HTML技術展現這些對象和數據，也可能你還有一堆HTC或其它的Javascript的HTML表現層控件。你的服務器端是一個Facade(或者是Adapter,Observer)模式的(Handler)控制器，接收客戶端Javascript的XML請求數據后，然后解析XML，然后調用相應的某個服務或業(yè)務組件，再將結果以XML的形式返回給客戶端Javascript，客戶端的Javascript接收之后，再進行處理和顯示，因為可以使用HTML的DOM 和CSS，所有頁面的展現是動態(tài)的。
　　這樣客戶端是中描述的Script-centric architecture 或Data-centric interactions的方式。而且這種方式和Jesse James Garrett列舉的Ajax是最類似的，只不過那時你或我不知道這個可以叫Ajax，只不過是現在的人誤解了Ajax，Ajax成了一種技術，一種特性，而首先不是一種某種架構下Web應用了。
　　而且目前流行的Ajax-NET的框架基本上都沒有實現雙向序列化，因為實現一個TextBox的自動完成客戶端只用接收數據就行了，根本不用傳回數據/對象到服務器端，同樣做一個Ajax的狀態(tài)進度條也不用，但這些都是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中，客戶端只用執(zhí)行eval(responseText)服務器端Rendered返回的HTML就可以了(很被動)。
　　由于DoPostCallBack 會提交ViewState以及AjaxPanelx$RBS_Store，幾乎是用XMLHttpRequest模擬一個正常的提交，所以服務器端可以創(chuàng)建頁面的實例也可以根據ViewState 恢復所有的控件狀態(tài)，同樣AjaxPanel以及AjaxControl 也都會實例化，然后接收客戶端傳來的_EventTarget, _EventArgument走正常的ASP.NET控件的處理過程，等控件Rendered之后，最終的HTML輸出被傳回客戶端，然后被客戶端的eval 顯示出來。
　　整個過程非常巧妙，這幾乎是ASP.NET __doPostBack 的"HookASP.NET"版和加強版本。而HttpModel主要是為了解決Session和交叉提交，進行客戶端Javascript的整理和注入，當然也是這里接收客戶端的請求，在Application_EndRequest中返回結果。剩下的代碼都是處理控件在VSWeb Design中的設計時支持。AjaxCallObject.js 和WebParts.js 每次都要傳到客戶端。
　　MagicAjax.NET 的一些不足和想法：
　　1、__doPostBack 的加強版，適合于ASP.NET的高級用戶使用
　　2、由于和ASP.NET的頁面處理機制依賴非常密切，控件的默認動作發(fā)生變化則可能不工作，比如第三方的某個自定義控件；
　　3、依賴ViewState，如果是加密的ViewState，則可能工作不正常，我沒有試，在代碼中好像沒有看見__VIEWSTATEENCRYPTED
　　4、是對ASP.NET 全部頁面提交的優(yōu)化，實現有限的Ajax功能，可擴展性不大
　　如果是基于ASP.NET 提供的控件和開發(fā)，那么MagicAjax.NET是非常有效的，很好的解決了Session和跨頁面狀態(tài)的問題。而且客戶端的操作和工作基本可以忽略，MagicAjax.NET設計貼近最近的ASP.NET的版本，目前不提供調用客戶端直接調用頁面的方法。但隨著其發(fā)展，優(yōu)勢可能漸少，因為Atlas最新的版本提供類似的UpdatePanel 控件。
　　2. Anthem.NET
　　目前是1.0版本，其設計理念是通過另外一個思路，遵循這樣的理念--既然ASP.NET的各個標準控件沒有實現提交功能，那么我可以產生一個提交的接口，然后繼承原來的標準控件，然后再實現這個接口，這樣每個控件都可以向服務器端單獨進行提交。
　　每個控件的發(fā)生過程類似MagicAjax.NET，Anthem.NET提供了各個控件Javascript端的提交函數－這等于也截取了__doPostBack，之后Anthem.NET還提供了完善的客戶端的事件比如PostCallBack 和PreCallBack這樣的客戶端事件，之后也將使用XMLHttpRequest模擬一個傳統(tǒng)的頁面提交請求到服務器端，服務器端生成頁面實例，這個過程和MagicAjax.NET一樣，最后是將Rendered的HTML在控件的Render()事件傳回到客戶端，客戶端控件的innerHTML被賦值，動態(tài)更新。
　　和MagicAjax.NET不同的是，Anthem.NET沒有容器的概念，因為每個控件都增加了提交接口，所以可以單獨的提交，所以單位是以一個控件為單位進行一次提交，Anthem.NET的花費更小些(但服務器端是類似的，因為整個ASP.NET頁面的Pipeline都會進行)。
　　此外，Anthem.NET還有另外的功能，就是可以通過客戶端調用頁面中的方法并獲得結果/數據，這種情況下，你將調用Anthem_InvokePageMethod方法，而不是Anthem.NET提供的默認各個控件的提交方法。這樣Javascript的回調處理函數中的result.value將可以獲得調用的服務端的某個方法(該方法以[Anthem.Method]為標記)的執(zhí)行結果，因為JavascriptPost的數據中有Page/MasterPage/Control了，那么服務器端很容易通過這個標識獲得方法的地址，應用反射尋找[Anthem.Method]標記，然后調用，將結果返回到客戶端。
　　Anthem.NET支持返回對象，DataSet，DataTable和WriteDataRow(WriteDataSet,WriteDataTable,WriteDataRow,WriteObject)，返回的是符合是JSON規(guī)范的字符串，這樣客戶端的Javascript就可以使用這些對象了。不同于MagicAjax.NET，Anthem.NET沒有使用HTTP Model，所以結果是在頁面的PreRender() 事件中處理和返回請求的結果。
　　2.1 Ajax.NET Professional
　　我沒有看過Ajax.NET Professional的源代碼，但從例子中看得其支持調用頁面的某個方法，以及返回對象，DataSet，DataTable的數據，我認為Ajax.NETProfessional 的實現和Anthem.NET 原理是一樣的，雖然Ajax.NET Professional 使用了HTTPModel，這個只是和Anthem.NET 一樣，最終處理結果的返回處理上稍有不同不同。比較起來，Ajax.NETProfessional 沒有重新繼承所有常用的ASP.NET控件實現部分提交的功能，所以可能Ajax.NETProfessional 比較強項的是調用頁面上的某個方法，并在客戶端獲得結果的數據，這個已經夠實現大部分的Ajax的功能了。
　　從這個層面上看，我認為Ajax.NET Professional 是相對笨重和復雜了。Anthem.NET不使用HTTPModel，提供控件基本的局部提交，也提供數據層面的客戶端方法調用。Ajax.NET Professional的源代碼似乎總是不想共享 ，這也是我不喜歡它的另外一個原因。
無論如何，大家都沒有提供兩路的數據交換，即客戶端可以獲得服務器端的方法并獲得結果和數據，但是目前都支持將這些對象/數據修改之后返回給服務器端。
　　Anthem.NET 的一些不足和想法：
　　1) Anthem.NET 也是一種"HookASP.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的優(yōu)點，同時又結合了ASP.NET的客戶端回調功能，是一個輕量級的Ajax組件。
　　看待wwHoverPanel 最大的兩個特性中的一個是用很簡單的方式實現了一個HoverPanelBehavior，這個實現比目前Atalas的Behavior 要簡單，作者Rick Strahl也強調這個主要是結合他具體的應用，比如這里提供了一個小的HTML板，可以顯示獲得的結果信息。
　　wwHoverPanel 也提供一個局部回調的方法，但是這點的實現上和MagicAjax.NET 以及Anthem.NET完全不同，它是使用一個StartCallback的Javascript來組合查詢字符串提交并且使用XMLHTTP發(fā)請求到服務器的某個頁面(由ServerUrl屬性指定)，之后這個頁面將結果以Response.Write()的原生HTML內容返回。這個和ASP.NET的回調方法非常類似，而且還支持將請求發(fā)到本頁之外的ASP.NET并獲得結果，所以它增強了原來ASP.NET的客戶端回調的方法，即支持其它頁面的回調。可以說，這是一種基于URL的客戶端回調。
　　wwHoverPanel提供的第二個功能是，客戶端可以調用服務器端中的某個頁面的方法(這些方法以[CallbackMethod]進行標識)，這種情況下，你要設置EventHandlerMode="CallPageMethod"，然后使用wwHoverPanel.服務器方法名(參數，參數，...，回調處理函數)的方式進行調用。這個其實使用的是一個Javascript的CallMethod方法，調用服務器端的請求。Javascript 的HandleCallback則用來處理返回的結果，邏輯相對簡單，盡管控件的innerHTML也被賦值，但這個主要是為了維護作為客戶端回調結果顯示的小的HTML板的內容，否則就是調用頁面中的方法了，那么結果就直接給客戶端的回調方法了。
　　特色三，就是我說的雙路的序列化功能了，其實這個場景我們也非常需要，比如我們用客戶端回調或XMLHTTP請求獲得了一個定單對象，那么客戶端修改之后，我還想把它作為一個客戶端調用的輸入參數，返回到服務器端。這時候兩路雙向的序列化就需要了，因為這次服務器需要將Javascript的函數傳了的數據序列化成.NET的類。這也就是JSON的雙向序列化了(主要代碼在JSONSerializer.cs)，這也是我挺喜歡的一個功能，因為我對這個功能關注很久，但是目前流行的Ajax-NET的框架都不支持這個功能。

　　目前在wwHoverPanel的場景中，我認為這是一種輕量級的實現，對于多層嵌套多組引用的對象圖類型或是大規(guī)模容量訪問壓力下，客戶端和服務器端都還需要優(yōu)化，所以如果其作為Ajax架構，客戶端和服務器端通信和傳遞數據的通訊層上，顯然是有些單薄了。

　　wwHoverPanel的一些不足和想法：

　　1)該控件是目前我見過.NET平臺下，惟一同時支持客戶端回調和頁面方法調用的Ajax控件，同時又支持兩路雙向的序列化。

　　2)相對來說，wwHoverPanel是設計最簡單的一個，而且是基于控件不依賴HTTPModel和ASP.NETPagePipeline，也不依賴ViewState

　　3)該控件能夠讓你在Ajax特性實現的技術層面上，能夠在客戶回調和客戶端調用頁面方法兩者中取得平衡。

　　4)目前的客戶端回調支持其它頁面的回調，但是其結果輸出需要輸出原始的HTML，這個影響應用的分層和設計。

　　5)JSON的雙向序列化是一個不錯的方案，但高性能的場景下，應該考慮實現更高效的序列化框架。

　　4.Atlas

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

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

　　最近的一個個版本-JanCTP，我們看到了一些特性，其強大之處在于：

　　1.客戶端(Javascript)的數據綁定、校驗帶來便利。

　　2.新的UpdatePanels不僅擁有了MagicAjax.NET的特性，而且功能更強，是目前Atlas中異步回調的主要控件。

　　3.內置了一些具體Ajax特性的控件，比如AutoCompleteExtender，DragOverlayExtender

　　4.提供了一些使用的控件比如，ScriptManager，Triggers，TimerControl

　　5.主要用途著重在提供一個客戶端控件和服務器端控件的特性集成的方案和容易使用的開發(fā)效率上。

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

　　1.客戶端的Behaviors還很弱，模板(Templates)和UI增強(UIEnhancements)功能還沒有看到。

　　2.所謂的客戶端Atlas控件(“Atlas”ClientControls)和服務器端的Atlas控件(“Atlas”ServerControls)還沒有一個明確的規(guī)范，所以現在你基本上還不能創(chuàng)建自定義的Atlas控件(無論客戶端還是服務器端的)。

　　3.目前還只支持調用WebServices的服務，對于ASP.NET的內置的服務以及WCF的服務支持也沒有看見，也不支持頁面或控件內的方法調用

　　4.功能上還不穩(wěn)定，一些功能僅是在特定條件下的特性實現，還不能滿足部署生產環(huán)境的要求。我認為，如果Atlas發(fā)布Go-LiveLicense，那么可以考慮Atlas的放入到正式的項目或應用中。

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

　　注：Atals的Microsoft.Web.Script.Serialization命名空間中有JavaScriptObjectDeserializer和JavaScriptObjectSerializer兩個對象，第一，我不確定其是否也是JSON序列化，而且我也不確定目前是否支持兩路雙向的序列化；第二，目前的版本，我還不能進行自定義或擴展，同時也很難對于其性能做任何的結論。
　　基于Ajax架構的Web應用框架

　　之前我提到過“似Ajax”的架構，現在我要說的Ajax框架也就是指專門針對這種Ajax架構而提供的框架。目前，我還沒有聽說過特別好的這個領域的流行框架。但我知道我的身邊，.NET領域，J2EE領域或PHP平臺上都有這樣的框架和應用，我認為，正是因為有很多這樣應用，所以Ajax才會像某個模式一樣，被撰有一個專門的名詞。不過我感覺Ajax漸漸變成了Ajaxfeature的代名詞，變成了XMLHTTP的代名詞，成了異步通訊，不刷新頁面的技術表示法。直到我看過AjaxinAction這本書，我才把Ajax和系統(tǒng)的架構、設計模式，分布式對象的序列化和我之前的項目和經歷聯系在一切。

　　我修改了一些Jesse的圖，來說明我認為的基于Ajax的架構是什么樣的。
　　這也就是我上面說的“似Ajax”架構，首先它是一個Web應用；它的表現層用DHTML＋CSS＋HTC控件＋Javascript，服務器端用.NET或任何的服務器端技術，中間以XML方式序列化和反序列化進行傳遞數據。

　　簡單的說，客戶端需要將請求的數據封裝成一個XML數據通過HTTP傳遞給服務器端，服務器端處理這個請求，并將結果也以XML的形式返回到客戶端，客戶端再處理這些請求，然后使用HTML+CSS進行展示。其實如果不是Web客戶端(瀏覽器)的問題，這是最簡單的架構，但關鍵問題在于上面我們說的Javascript端的對象封裝成一個XML，以及到服務端解析XML變成服務器端對象，然后再將結果封裝成XML，傳回給客戶端(Javascript)，客戶端也解析XML數據，然后變成Javascript中的對象的這個序列化和反序列化的問題。另外一個問題就是表現層的展現問題，怎么展現，用什么控件？

　　所以，一個Ajax架構的Web應用程序，必須解決下面的問題：

　　1.雙向兩路的序列化問題

　　2.表現層展現的問題

　　3.傳輸時客戶端和服務器端的數據安全問題

　　4.性能問題

　　5.國際化支持

　　最好玩的雙向兩路的序列化問題，最早接觸的是JSON，它的問題在于擴展性，數據類型的支持和性能，但是平臺無關性比較好，什么瀏覽器都可以，因為它不需要用msxml2.DOMDocumen分析XML，本質上就是用字符串描述對象；之后多平臺的應用的遷移經歷中(比如CORBAR，J2EE的后臺應用)，開始接觸到XML-RPC，ICE，Hessian，WebServices等等。其中XML-RPC有Javascript的支持庫，WebServices也有Javascript的支持庫，也就是你可以使用Javascript訪問或者獲得XML－RPC/WebServices的對象，但是如果你將其作為一個主要的通訊協(xié)議，那么就會遇到另外一些問題，比如性能、國際化的問題，又會困擾你，XML-RPC和WebServices的一個主要問題都是性能，因為他們傳輸的XML大小都太大了，但顯然用這些實現一個Ajax的特性，那是完全沒有問題了。

　　比如，Atlas目前不也是使用一個Javascript庫調用WebServices嗎？，所以，你也可以這么做，同樣你也可以用XML-RPC.NET很快就可以實現一個Service，然后使用Scotandrew的XML-RPCjavascript庫就可以在Javascript中發(fā)一個XML-RPC消息請求這個服務，然后異步的獲得這個結果，然后展現它。所以從技術的實現上講，Ajax的特性非常容易實現，但從架構上來看。你需要思考更多的因素。當然直到最后，我們才發(fā)現，在項目中，最完美的方案是你自己寫一個雙向兩路的序列化引擎供你的Javascript客戶端使用。

　　這就說到了第二個問題，界面表現的問題，這個問題也是一個大的問題。這個問題一直會永遠存在，Ajax之前沒有人會太注意這些，但今天不同了，我想未來還會有很大的一個飛躍，Yahoo！不是最近也開源了他的Yahoo！WebUI庫，Atlas也表示要提供更多的前端UI控件。無論如何，這個問題是，你的團隊或組織是否有一套經過項目或客戶檢驗的前端Javascript的庫。無論是自己用Javascript寫的也好，是自己寫的一套HTC的控件庫也好，總之這些是Ajax架構中非常重要的一環(huán)。

　　Atlas帶來了另外一個思考問題，就是服務器端控件可能可以通過某種方式和Javascript的控件很好的集成在一起，以前我們用HTC解決了重用、性能、Behaviors、甚至模板功能。但是新的特性還是有比如數據的綁定、緩存和校驗、甚至是數據編碼和壓縮、加密和解密，JavascriptUI前端還是有許多可以做的，而且如何無縫的集成兩者，這個有非常大的意義。

　　接著安全、性能、國際化等等，架構中的問題需要你依次考慮和解決，如果這么看Ajax，我認為，目前的Ajax框架還有很長很長一段路要走，同樣真正完美支持Ajax架構的還需要繼續(xù)努力。這些也是我在這篇專欄文章中的觀點。

　　把這些合在一起，那么Ajax架構的開發(fā)包或框架，就應該是包含了上述幾個問題(兩路雙向的序列化、JavascriptUI表現庫、安全、國際化和性能等等)解決方案的一個平臺實現。

　　同樣也許你會說，不就是Ajax嗎？我干嘛要搞這么復雜，一定要搞到架構這個層面。

　　我認為，

　　第一，從架構的層面看Ajax，然后再應用相關的技術，比你直接使用某個Ajax框架然后再理解Ajax，你會從這個過程中收獲更多。

　　第二，對于一個開發(fā)團隊/組織來說，真正Ajax架構的產品，可以帶來效益和具體的生產力。比如，我身邊就有擁有這樣的優(yōu)勢的團隊，他們擁有一套統(tǒng)一的由Javascript+HTML+CSS+HTC的前端表現層，而后臺的業(yè)務系統(tǒng)有兩個平臺，一個.NET平臺和J2EE平臺；同樣我身邊的也有這樣的團隊，他們擁有一套統(tǒng)一的由Javascript+DHTML+CSS+HTC＋VML+ASP.NET的前端表現層，但他們的后臺業(yè)務層分別來自.NET平臺、J2EE平臺和Unix平臺，我不能說Ajax架構的應用似乎就是統(tǒng)一Web表現層。因為從今天看到他們的明天，也許會是，一個ASP.NETV2+Atlas的統(tǒng)一表現層，一個統(tǒng)一CAB+SmartClient的統(tǒng)一表現層，也可以是一個WPF3D的統(tǒng)一表現層，也可以是一個Xgl桌面的統(tǒng)一層......

　　第三，從這架構的層面上，你也能夠非常容易理解SOA或ESB概念，和SOA相比，Ajax架構的區(qū)別在于，Ajax有足夠的松散耦合，但它依然以應用的數據為中心，更多的是一個面向Messages的架構，而且對于流行的WS-*協(xié)議的支持非常有限。

　　但是假如，今天你或你的團隊已經有了一個Ajax架構的應用，那么你是不是應該要小心選擇現有的Ajax框架，因為這些Ajax的特性，相對于目前的架構來說，是多么小，但又可能會產生很大危害的一個因素。也許這樣的團隊并不多，也許也很多，但是只有我們從更高更深的層次來思考，那么我們就能做出正確的選擇，并且從新的Ajax技術和研究中獲得好處。

　　結論

　　當我們回到文章的起點，我希望這樣能夠說明的我觀點，即Ajax-NET的框架或實現分為兩類，一類是基于Ajax應用程序架構的，一類是基于Ajax特性的，目前幾乎大部分的Ajax-NET的框架或實現都是基于Ajax特性，以Add-in方式提供的代碼或框架。

　　Ajax-NET的實現/框架選取上的建議：

　　ASP.NET控件形式已經成為連接服務器和客戶端Ajax通信的主要形式和選擇。

　　客戶端調用服務器端頁面中的方法是Ajax的重要手段，使得客戶端可以更加靈活的獲得服務器端的數據。

　　MagicAjax.NET，Anthem.NET用了“HookASP.NET”和Add－In的技術手段，使用上受到的影響比較多，這兩個框架中，最簡單的應用，第一選擇MagicAjax.NET，但總是優(yōu)先使用Anthem.NET。

　　如果是自己寫的服務器端控件，那么應該先掌握Anthem.NET的技術，然后使自己的控件擁有Ajax的特性。

　　MagicAjax.NET，Anthem.NET和wwHoverPanel對于國際化的支持都有待加強。

　　在Atlas沒有正式發(fā)布之前，在ASP.NET的應用中優(yōu)先在自己的項目中使用類似wwHoverPanel的技術，即盡可能的使用客戶端回調功能，在特別需要的地方使用其方法調用的功能，充分發(fā)揮Ajax的特性，而不要因為Ajax而特意選擇某個Ajax的框架。

　　Atlas的強項在于服務器端和客戶端控件特性的集成、客戶端的數據綁定、校驗、內置的多個客戶端Ajax特性UI或組件，與ASP.NET的Profile，Membership，Role服務的集成，與WebServices和WCF服務的集成，以及良好的國際化/開發(fā)工具支持的。因為它是一個完整的解決方案，所以最大的弱點是不能很容易地被老的Ajax架構的應用使用。另外該產品目前還在不斷開發(fā)中，距離部署到生產環(huán)境中的要求還有差距。

　　輕量級的雙向序列化可以考慮JSON格式，安全問題可以在傳遞的對象中增加字段，然后在服務器端進行校驗。

　　對于原來已經有一套序列化框架的組織來說，其主要的目標是盡快將這個框架遷移/升級到ASP.NETV2，而不是優(yōu)先考慮實現某個Ajax的特性。

　　Ajax要求有足夠的力量關注前端的UI展現或開發(fā)，所以對Ajax實現/框架的選擇，最先要考察其客戶端的實現以及提供的WebUI。

　　看完這篇文章，我希望，今后我們再談起Ajax的時候，作為技術人員，我不用談論什么Web2.0，我一樣可以清楚的表達Ajax的概念
　　如果你是一個架構師，Ajax不再是什么異步的XMLHTTP調用，不再是不刷新頁面，它可以幫忙你Review應用程序的架構。

　　對于你的團隊或老板來說，Ajax可以是你統(tǒng)一界面表現層的一個策略，同樣也可能讓你有了一個創(chuàng)建一套部門或公司級能夠重用的UI類庫的機會。

　　同樣對于Javascript的開發(fā)人員來說，Ajax讓你們還需要了解一些業(yè)務，并證明前臺的Web開發(fā)人員一樣很昂貴，后臺開發(fā)也可以是技術含量不高的。

　　對于SOA的愛好者來說，Ajax架構讓你能夠站在面向消息的架構和系統(tǒng)上來看面向服務；一般我們說，對內你首先要有一套面向消息的架構，然后對外你就很容易延伸成一個面向服務面向Internet的分布式架構。

　　最后，不要討論Ajax的消亡，因為Ajax對于程序員來說，是一種力量均衡的策略，在Ajax中，Web前端的開發(fā)人員被重新重視，成為一支重要的力量。

　　后記

　　寫這些文字的某幾個段落，讓我有些痛苦，因為我本來沒想些這么多。所以你不要太在意我對各個框架的評價和描述，這些都是技術的層面的東西，其實我寫這篇文字，主要是想突出Ajax的架構觀，以及設計模式和Web應用架構重構的考慮，續(xù)而你也能夠用類似橫切面的角度，用Ajax來看你目前的應用和架構，從而更深的了解分布式對象的序列化、性能、安全以及Ajax和ASP.NET服務器端控件的融合。最后歡迎大家斧正。