使用AJAX技術開發新一代Web應用程式 1

　 一、引言

　　一個理想的使用者介面對使用者最好是不可見的-僅在使用者需要時提供選擇，否則並不干涉他們的工作而讓其專註於手頭的工作。然而，這並不是一件容易的事情。如今，我們變得習慣於通過並不十分令人滿意的UI進行日常工作，直到有人向我們展示一種更好的方法。現在，我們才逐漸認識到我們當前的方法在做這些事情時是多麼吃力。

　　由於用於顯示文檔內容的基本web瀏覽器技術又被推進一步進而超出以前它們所能及的範圍，所以，如今的互連網正在經曆著這樣的實現。

　　Ajax(非同步JavaScript+XML)是一個非常新的名字，為Adaptive Path的Jesse James Garrett所建立。其中，Ajax的某些部分以前被描述為動態HTML和遠程指令碼。

　　Ajax的出現不僅僅是一個新名字的問題。從技術和商業的角度看，圍繞Ajax還有大量激動人心的東西。從技術上講，Ajax實現了web瀏覽器技術中大量的尚未實現的潛力。從商業上看，Google和其它一些主要商家正在逐步使用Ajax技術，從而讓公眾認識到一個web應用程式所能做的事情。

　　以前我們習慣的典型web應用程式如今正在承受著巨大的壓力，因為逐漸複雜的基於全球資訊網的服務正日趨成熟並開始應用於互連網。各種新技術爭相湧現出來以克服這些問題，而Ajax僅使用現有的互連網技術就能夠更好地表達這些思想。

　　利用Ajax，我們重用了一堆原有技術但卻擴充了它們原來所能及的範圍。我們需要能夠管理這種我們引入的複雜性。本文將討論怎樣實現這些技術，而且還要討論一下管理大型Ajax工程的問題。我們將介紹Ajax設計模式及其怎樣協助我們完成工作。設計模式協助我們捕獲我們的知識和經驗，用我們現在的技術並且使之與其它對象進行通訊。通過把規則引入到代碼基之上，它們就能夠方便建立應用程式-可以據變化對工程加以修改和擴充。使用設計模式進行開發甚至是一種喜悅！

　　為什麼說Ajax是豐富的用戶端？

　　構建一個豐富的用戶端介面比設計一個WEB頁面要複雜。那麼是東西導致我們這樣做的？好處有哪些？什麼是豐富的用戶端?

　　一個豐富的用戶端有兩個關鍵特點：它是豐富的，而且它是一個用戶端。

　　讓我稍作解釋。豐富指的是用戶端方式。一個豐富的用戶端模型-是指它能夠支援各種輸入方法且能夠直觀又非常及時地作出響應。儘管我們稱其為"豐富的"，但是它必須與象文書處理器和工作表等現代傳統型應用程式一樣好才真正豐富。下面讓我們看一下為達此目的所具體要求的實現技術。

　　二、比較使用者體驗

　　在這裡，讓我們討論一個工作表程式的執行個體。當我在工作表輸入一些簡單的公式時，我可以有幾種方式與之互動-現場編輯資料，用鍵盤和滑鼠導航資料和通過滑鼠拖動重新組織資料。

　　當我在操作這些時，軟體給我反饋-滑鼠游標形狀改變，當我在按鈕上移動時按鈕高亮，選定的文本改變顏色，高亮的視窗和對話方塊以不同形式顯示，等等（圖1）。

圖1 這個案頭工作表應用程式說明了多種使用者互動的可能性。

　　這些是當今使用者豐富的互動的主要表現。這樣的工作表應用程式就是一個豐富的用戶端嗎？還不是。

　　在一個工作表或類似的傳統型應用程式中，邏輯和資料模型都在一個封閉的環境中運行-在此它們彼此都能清晰可見，但是卻把外界拒之門外（圖2）。我的用戶端定義是一個程式-它能夠與一個不同的獨立的進程通訊-典型地它運行於一個伺服器上。傳統地，該伺服器比用戶端更大更強壯並且儲存了海量資訊。用戶端允許終端使用者觀看和修改這些資訊，並且如果有一些客戶串連到同一個伺服器上，它允許他們分享該資料。圖3顯示出一客戶機/伺服器架構的簡單圖解。

圖2 一個獨立傳統型應用程式的圖解架構。

　　該應用程式運行於其自身的進程之中-在其內資料模型和程式邏輯彼此清晰可見。在同一台電腦上啟動並執行該應用程式的第二個執行個體除了經由檔案系統之外無法存取第一個執行個體的資料模型。典型地，全部程式狀態儲存在單個的檔案中-當該應用程式運行時它被鎖定以阻止任何資訊的同步交換。

圖3 用戶端/伺服器系統和n層架構圖解。

　　該伺服器提供一個客戶可以用之進行互動的可共用的資料模型。用戶端仍然維持它們自己的部分資料模型以達到快速存取。多個客戶可以與同一個伺服器進行互動，而此時在單個對象或資料庫行良好粒度級上控制的資源被鎖定。該伺服器可以是一個單個的進程，就象在90年代以前的早期的傳統型用戶端/伺服器模型或由若干中介軟體層、外部web服務等組成的現代模型。在任何情況下，從客戶的角度來看，伺服器具有單個進入點並且可以被認為是一個黑盒子。

　　當然，在一現代的N層架構中，伺服器將能與例如資料庫這樣的後端伺服器通訊-這導致了中介軟體層的出現-它們既充當用戶端又充當伺服器端。典型地，我們的Ajax應用程式位於這個鏈的一端上-只擔當用戶端，所以我們可能把整個N層系統看作單個黑盒子-我們把它標記為伺服器，以便於我們當前的討論。

　　我的工作表只專註於它自己的儲存在本地記憶體和本地檔案系統上的資料。如果它架構良好，資料層和描述層之間的耦合可能相當鬆散，但是我無法把它通過網路分解與共用。所以，從我們的描述層目標來看，它不是一個用戶端。

　　當然，Web瀏覽器是用戶端，它串連web伺服器並從中進行頁面請求。這些瀏覽器具有一些豐富的功能來系統管理使用者的web瀏覽，例如後退按鈕、曆史列表和多頁面儲存多個文檔。但是如果我們把一個特定網站的web頁面看作一個應用程式，那麼這些通用瀏覽器控制便不能再關聯到應用程式，就象Windows開始菜單或window列表相關於我的工作表一樣。

　　讓我們看一個現代web應用程式。主要因為每個人可能都聽說過它，所以我們將選擇Amazon-線上書商為例(圖4)。現在，我把自己的瀏覽器指向Amazon網站；因為該網站從我的上次訪問能夠記得我是誰，所以它先給我顯示一個友好的問候、推薦書列表和關於我已購買書的曆史資訊。

圖4 Amazon.com首頁。該系統記得我以前訪問過該網站，其中可導航的連結是通用資訊和私人資訊的混合。

　　從建議列表中點擊一個標題將把我導向一個獨立的頁面(也即，該螢幕閃爍一下，於是我就失去了幾分鐘前可以看到的列表)。於是新頁面中又會充滿各種上下文資訊（見圖5）。

圖5 Amazon.com網站書籍詳細資料頁面。

　　再一次，大量的結合有通用和私人資訊的超連結出現。儘管如此，大量的細節與圖4所示極為相同-這，由於web瀏覽器的基於文檔的操作，必須被重新轉送到每個頁面。

　　簡言之，我向你展示了非常豐富的緊密聯絡的資訊。而且我與這種資訊互動的唯一方式是通過點按超連結並且填寫文本表單。如果我在瀏覽網站時的鍵盤輸入過程中睡著了並且第二天才醒來，那麼在我重新整理全部頁面之前我不會知道新的哈裡·傳輸速率書已經發行。我不可能帶著我的列表從一個頁面轉到另一個頁面，並且我不可能縮放該文檔的一部分來一次觀看多處的內容。

　　這並不是在詆毀Amazon，在非常有限的限定內它工作得相當優秀。但是與工作表相比，它所依賴的互動模型毫無疑問相當有限。

　　那麼，為什麼在現代web應用程式中存在這麼多的限制呢？目前，存在很多技術上的原因。因此，現在讓我們作進一步分析。