Thinking in AJAX(二) —— 基於AJAX的WEB設計

文章目錄

• 一、AJAX最值得稱讚的是非同步互動，而不是無重新整理
• 二、推薦在WEB上輕量級的應用AJAX
• 三、AJAX的MVC架構設計

一、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的本意，雖然像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亦可。