在這裏我將試圖考察一下目前.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，所有頁面的展現是動態的。
這樣客戶端是<Ajax in Action>中描述的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 每次都要傳到客戶端。
