衆所周知，異步交互、JavaScript腳本和XML封裝數據是AJAX的三大特徵。其實，在實際應用中，不需要牢牢套死這三條大律，在我看來， AJAX - X，即去掉用XML封裝數據，也不失爲一種好的設計思路，如果應用恰當，更顯輕盈步伐和巧妙思路。
一 般讀取AJAX返回的XML結構的數據時使用XMLHttp的responseXML對象屬性，同時，XMLHttp也提供了另外一個屬性，即 ResponseText，通過這個屬性，XMLHttp可以接受來自服務器的文本結構的字符串信息。去掉XML的AJAX可以使用 ResponseText這個對象屬性，很靈活的操控返回數據的格式，可以自定義格式，比如我通常喜歡用c語言的那種文件流方式定義返回的字符串結構，有 文件頭和具體的文件信息實體，文件頭分爲狀態信息以及文件字符長度，我摒棄了文件字符長度的定義，規定死接受的ResponseTex字符串中的第一位爲 狀態碼，比如設定常量值0表示一起正常，非0的數字表示不正常，甚至有錯誤等。如果有非0值，程序自動取第二位起到257位(長度爲256)的字符串組成 爲狀態信息，從258位開始到末尾的字符串就是服務器返回的正常結果信息。
substring(0,1)取狀態碼
substring(1,256)取服務器錯誤信息(錯誤信息不夠256位用空格補齊，取到數據後進行Trim處理)
substring(256,末尾)取服務器返回的數據信息
三次substring即完成了一個簡單但完整的交互工作。比起XML解析組件來說要快的多。
用ResponseText比封裝爲XML處理數據快和簡單是一個原因，另一個原因是可操控性更大更靈活，打開Google Suggest，在搜索框輸 入字符可以給你給出拼寫提示，Suggest就是應用了AJAX技術，不過它在從服務器返回數據時並沒有使用XML封裝，也沒有自定義 ResponseText格式，而是直接將返回代碼組織成js腳本，通過瀏覽器返回後直接執行，如eval(XMLHttp.ResponseText) 這樣的方式進行執行，http://www.google.com/complete/search?hl=en&js=true&qu=ajax 通過這個鏈接你可以看到Suggest利用AJAX得到的返回數據，此頁面是在Google Suggest的搜索框中輸入"AJAX"後得系統動態返回的數據。
sendRPCDone(frameElement, "ajax", new Array("ajax", "ajax amsterdam", "ajax fc", "ajax ontario", "ajax grips", "ajax football club", "ajax public library", "ajax football", "ajax soccer", "ajax pickering transit"), new Array("3,840,000 results", "502,000 results", "710,000 results", "275,000 results", "8,860 results", "573,000 results", "40,500 results", "454,000 results", "437,000 results", "10,700 results"), new Array(""));
瀏覽器段拿到這段代碼後直接eval就可以了，至於sendRPCDone這個函數，那當然得實現定義後並裝載到頁面中啦。XMLHttp這個名字以XML開頭，讓很多人禁錮了思想和創意，完全拋棄X，你也可以做出純AJAX的實例來。
當 然，對於大型系統來講，爲了保持數據接口的一致和整齊，還是用XML來傳遞更嚴謹更統一點，聽說微軟已經發起了重寫XML Parse組件的號召，估計下 一個版本的XMLHttp還是DOMParser還是MSXML2.DOMDocument都會大大提高效率，減少資源佔用的。
一、AJAX最值得稱讚的是異步交互，而不是無刷新
很多人都看好AJAX無刷新的技術，以至於認同AJAX就是用來做無刷新的。這個認識是錯誤的，什麼是無刷新？無刷新就是頁面無需重載，那什麼又是異步交 互？異步交互就是一個簡單的多線程，當你在一個blog裏看文章時，同時也可以利用AJAX進行無刷新的回覆提交，看起來雖然也是無刷新，但這裏最重要的 是異步，即你能一邊看文章，一邊又能向服務器提交你的回覆信息，利用好這個異步，才能算是掌握了AJAX的精髓。很多場合，無刷新是呈現給用戶的視覺體 驗，而異步交互卻是默默無聞的工作在臺後，這種情況導致大多數人的錯誤理解了AJAX的權重之分。
二、推薦在WEB上輕量級的應用AJAX
著 名的圖片存儲網站Flickr利用AJAX可謂出神入化。我之所以這麼說，是因爲我認爲Flickr深知AJAX的利與弊，並且牢牢抓住自己的網站的功能 特點，並沒有因AJAX而AJAX，而是架驅於技術至上，讓AJAX融於網站之中，爲網站提供了更好的功能服務。如Flickr中無論是在多圖列表頁面還 是單圖詳細頁面，修改圖片的標題和描述都應用了AJAX技術，讓用戶無需跳轉到單獨的編輯頁面中，編輯後單擊保存，亦使用了異步交互的方式進行數據提交， 這時，頁面上顯示一個Loading字符外，其他部分不受任何影響，可謂太貼心的服務。
再如基於Tag的專業Blog搜索服務 商Technorati也使用了AJAX，在搜索某個Tag時，頁面主導部分會即刻顯示所有Technorati數據庫中查詢到的數據條目，在左邊的側邊 欄上會顯示兩個Loading圖標，過一會兒，這兩個Loading就會顯示具體的內容了，顯示的是此Tag相關的Flickr的圖片和書籤服務網站 (Furl&del.icio.us)的鏈接，因爲這兩部分內容是取自其他網站，如果由服務器統一先取得數據在一同顯示到頁面時，會受到網速影響 而變慢，通過AJAX的異步交互方式首先立即顯示本地數據，然後由客戶端去和Flickr、Furl、del.icio.us打交道分別取得它們的數據， 即節約了流量帶寬又不影響用戶訪問速度，可謂高明。
通過以上兩個國外成功應用AJAX的網站，我們發現他們都使用的是輕量級的AJAX，就是那種交互簡單，數據較少的操作。這也符合AJAX的本意，雖然像http://www.backbase.com/和bindows都在RIA上有驚人的表現能力，但是速度慢、搜索引擎支持不好、開發難度大等毛病還是無法讓用戶滿意的，請記住：AJAX的最終目的是爲了提高用戶體驗，爲了方便用戶交互，而不是因技術而技術的。
三、AJAX的MVC架構設計
很 多人認爲在成熟的框架中應用AJAX會破壞框架的完整性，比較常見的說法有三層架構的WEB應用中破壞MVC模式，其實不然。MVC的理論我就不多說了， 經典的那三個層、五條線大家都很熟悉，在WEB應用中，因爲瀏覽器/服務器固有的這種請求/響應的斷開式網絡通訊模式，決定了在Model層無法實現主動 向View層發出數據更新事件，所以一般常見的成熟MVC框架中都將經典MVC理論稍作修改：由Model層處理完業務後通知Control層，然後由 Control層承擔向View發送數據更新的義務。但是AJAX天生具有監聽功能，AJAX實現異步響應的那個OnReadyStateChange事 件就具有在客戶端程序中纔會有的事件監聽功能。現在想來，利用AJAX實現的MVC模型有如下圖這樣：
![]()
理想化的設計如下所示：
三層對應的文件對象：view.jsp(視圖)、action.do(控制器)、model.java(模型)
view.jsp是用戶看到的界面，並通過內置的AJAX對象異步方式給action.do發送請求，AJAX.OnReadyStateChange開始監聽
action.do接收到view.jsp發過來的請求(GET或者POST方式)，通過Request判斷後發送給相應的業務/數據模型model.java
model.java 開始執行業務操作，執行完畢直接給view.jsp頁面發送數據更新的通知，這個通知的消息有可能是XML封裝的數據，也有可能是一段文本，甚至是一段 HTML代碼，當然，既然用MVC，不推薦有Model發送HTML，推薦還是用XML封裝業務數據即可。
view.jsp頁面中AJAX對象的OnReadyStateChange接收到了數據更新通知，根據實際情況用DOM進行頁面呈現更新。
通 過以上幾步一氣呵成，一個典型的基於MVC的三層交互就完成了。當然，熟悉WEB下的MVC框架的用戶，如熟悉Struts的Java開發人員可能不習慣 由Model層給View直接發送數據更新通知，那咱們也可以轉變一下，Model層業務處理完畢將更新通知先發送給Control，由Control去 通知View亦可。
一 般讀取AJAX返回的XML結構的數據時使用XMLHttp的responseXML對象屬性，同時，XMLHttp也提供了另外一個屬性，即 ResponseText，通過這個屬性，XMLHttp可以接受來自服務器的文本結構的字符串信息。去掉XML的AJAX可以使用 ResponseText這個對象屬性，很靈活的操控返回數據的格式，可以自定義格式，比如我通常喜歡用c語言的那種文件流方式定義返回的字符串結構，有 文件頭和具體的文件信息實體，文件頭分爲狀態信息以及文件字符長度，我摒棄了文件字符長度的定義，規定死接受的ResponseTex字符串中的第一位爲 狀態碼，比如設定常量值0表示一起正常，非0的數字表示不正常，甚至有錯誤等。如果有非0值，程序自動取第二位起到257位(長度爲256)的字符串組成 爲狀態信息，從258位開始到末尾的字符串就是服務器返回的正常結果信息。
substring(0,1)取狀態碼
substring(1,256)取服務器錯誤信息(錯誤信息不夠256位用空格補齊，取到數據後進行Trim處理)
substring(256,末尾)取服務器返回的數據信息
三次substring即完成了一個簡單但完整的交互工作。比起XML解析組件來說要快的多。
用ResponseText比封裝爲XML處理數據快和簡單是一個原因，另一個原因是可操控性更大更靈活，打開Google Suggest，在搜索框輸 入字符可以給你給出拼寫提示，Suggest就是應用了AJAX技術，不過它在從服務器返回數據時並沒有使用XML封裝，也沒有自定義 ResponseText格式，而是直接將返回代碼組織成js腳本，通過瀏覽器返回後直接執行，如eval(XMLHttp.ResponseText) 這樣的方式進行執行，http://www.google.com/complete/search?hl=en&js=true&qu=ajax 通過這個鏈接你可以看到Suggest利用AJAX得到的返回數據，此頁面是在Google Suggest的搜索框中輸入"AJAX"後得系統動態返回的數據。
sendRPCDone(frameElement, "ajax", new Array("ajax", "ajax amsterdam", "ajax fc", "ajax ontario", "ajax grips", "ajax football club", "ajax public library", "ajax football", "ajax soccer", "ajax pickering transit"), new Array("3,840,000 results", "502,000 results", "710,000 results", "275,000 results", "8,860 results", "573,000 results", "40,500 results", "454,000 results", "437,000 results", "10,700 results"), new Array(""));
瀏覽器段拿到這段代碼後直接eval就可以了，至於sendRPCDone這個函數，那當然得實現定義後並裝載到頁面中啦。XMLHttp這個名字以XML開頭，讓很多人禁錮了思想和創意，完全拋棄X，你也可以做出純AJAX的實例來。
當 然，對於大型系統來講，爲了保持數據接口的一致和整齊，還是用XML來傳遞更嚴謹更統一點，聽說微軟已經發起了重寫XML Parse組件的號召，估計下 一個版本的XMLHttp還是DOMParser還是MSXML2.DOMDocument都會大大提高效率，減少資源佔用的。
一、AJAX最值得稱讚的是異步交互，而不是無刷新
很多人都看好AJAX無刷新的技術，以至於認同AJAX就是用來做無刷新的。這個認識是錯誤的，什麼是無刷新？無刷新就是頁面無需重載，那什麼又是異步交 互？異步交互就是一個簡單的多線程，當你在一個blog裏看文章時，同時也可以利用AJAX進行無刷新的回覆提交，看起來雖然也是無刷新，但這裏最重要的 是異步，即你能一邊看文章，一邊又能向服務器提交你的回覆信息，利用好這個異步，才能算是掌握了AJAX的精髓。很多場合，無刷新是呈現給用戶的視覺體 驗，而異步交互卻是默默無聞的工作在臺後，這種情況導致大多數人的錯誤理解了AJAX的權重之分。
二、推薦在WEB上輕量級的應用AJAX
著 名的圖片存儲網站Flickr利用AJAX可謂出神入化。我之所以這麼說，是因爲我認爲Flickr深知AJAX的利與弊，並且牢牢抓住自己的網站的功能 特點，並沒有因AJAX而AJAX，而是架驅於技術至上，讓AJAX融於網站之中，爲網站提供了更好的功能服務。如Flickr中無論是在多圖列表頁面還 是單圖詳細頁面，修改圖片的標題和描述都應用了AJAX技術，讓用戶無需跳轉到單獨的編輯頁面中，編輯後單擊保存，亦使用了異步交互的方式進行數據提交， 這時，頁面上顯示一個Loading字符外，其他部分不受任何影響，可謂太貼心的服務。
再如基於Tag的專業Blog搜索服務 商Technorati也使用了AJAX，在搜索某個Tag時，頁面主導部分會即刻顯示所有Technorati數據庫中查詢到的數據條目，在左邊的側邊 欄上會顯示兩個Loading圖標，過一會兒，這兩個Loading就會顯示具體的內容了，顯示的是此Tag相關的Flickr的圖片和書籤服務網站 (Furl&del.icio.us)的鏈接，因爲這兩部分內容是取自其他網站，如果由服務器統一先取得數據在一同顯示到頁面時，會受到網速影響 而變慢，通過AJAX的異步交互方式首先立即顯示本地數據，然後由客戶端去和Flickr、Furl、del.icio.us打交道分別取得它們的數據， 即節約了流量帶寬又不影響用戶訪問速度，可謂高明。
通過以上兩個國外成功應用AJAX的網站，我們發現他們都使用的是輕量級的AJAX，就是那種交互簡單，數據較少的操作。這也符合AJAX的本意，雖然像http://www.backbase.com/和bindows都在RIA上有驚人的表現能力，但是速度慢、搜索引擎支持不好、開發難度大等毛病還是無法讓用戶滿意的，請記住：AJAX的最終目的是爲了提高用戶體驗，爲了方便用戶交互，而不是因技術而技術的。
三、AJAX的MVC架構設計
很 多人認爲在成熟的框架中應用AJAX會破壞框架的完整性，比較常見的說法有三層架構的WEB應用中破壞MVC模式，其實不然。MVC的理論我就不多說了， 經典的那三個層、五條線大家都很熟悉，在WEB應用中，因爲瀏覽器/服務器固有的這種請求/響應的斷開式網絡通訊模式，決定了在Model層無法實現主動 向View層發出數據更新事件，所以一般常見的成熟MVC框架中都將經典MVC理論稍作修改：由Model層處理完業務後通知Control層，然後由 Control層承擔向View發送數據更新的義務。但是AJAX天生具有監聽功能，AJAX實現異步響應的那個OnReadyStateChange事 件就具有在客戶端程序中纔會有的事件監聽功能。現在想來，利用AJAX實現的MVC模型有如下圖這樣：
理想化的設計如下所示：
三層對應的文件對象：view.jsp(視圖)、action.do(控制器)、model.java(模型)
view.jsp是用戶看到的界面，並通過內置的AJAX對象異步方式給action.do發送請求，AJAX.OnReadyStateChange開始監聽
action.do接收到view.jsp發過來的請求(GET或者POST方式)，通過Request判斷後發送給相應的業務/數據模型model.java
model.java 開始執行業務操作，執行完畢直接給view.jsp頁面發送數據更新的通知，這個通知的消息有可能是XML封裝的數據，也有可能是一段文本，甚至是一段 HTML代碼，當然，既然用MVC，不推薦有Model發送HTML，推薦還是用XML封裝業務數據即可。
view.jsp頁面中AJAX對象的OnReadyStateChange接收到了數據更新通知，根據實際情況用DOM進行頁面呈現更新。
通 過以上幾步一氣呵成，一個典型的基於MVC的三層交互就完成了。當然，熟悉WEB下的MVC框架的用戶，如熟悉Struts的Java開發人員可能不習慣 由Model層給View直接發送數據更新通知，那咱們也可以轉變一下，Model層業務處理完畢將更新通知先發送給Control，由Control去 通知View亦可。
