在這個(gè)共分兩部分的系列文章的 第 1 部分中，我們討論了對于那些需要動(dòng)態(tài)和個(gè)性化的用戶(hù)界面，同時(shí)又要求可伸縮性的 Web 應用程序來(lái)說(shuō)，Ajax/REST架構風(fēng)格可能帶來(lái)的好處。給定這些需求之后，我解釋了為什么相對于傳統的服務(wù)器端 Web 應用程序架構風(fēng)格來(lái)說(shuō)，Ajax/REST極為出色。但只有在您成功設想、規劃、開(kāi)發(fā)、測試和部署了 Ajax 應用程序之后，用戶(hù)才能享受這些美好的運行時(shí)特性。本文說(shuō)明了 Ajax/REST應用程序的開(kāi)發(fā)時(shí)特性的問(wèn)題。其目標是為那些有興趣在實(shí)際應用程序中使用 Ajax 的讀者解答兩個(gè)重要的問(wèn)題：

• 是否應該在自己的 IT 應用程序中使用 Ajax 技術(shù)嗎？
• 如果答案是肯定的，那么應怎樣來(lái)提高成功開(kāi)發(fā)和部署 Ajax 技術(shù)的機會(huì )？

Ajax/REST 架構風(fēng)格的新興給使用傳統服務(wù)器端 Web 應用程序風(fēng)格的組織帶來(lái)了一些挑戰。盡管與傳統模型相比，Ajax具有許多引人注目的架構優(yōu)點(diǎn)，但立即全面轉換成純粹的 Ajax/REST 架構對于所有組織來(lái)說(shuō)并不現實(shí)。那些缺乏 Ajax開(kāi)發(fā)技巧的組織可向現有服務(wù)器端 Web 架構逐漸、增量式地添加 Ajax 功能，從而開(kāi)始采用 Ajax 技術(shù)。隨著(zhù)這些組織在 Ajax/REST使用方面的經(jīng)驗逐步增加，他們就可以安心地嘗試更有趣、更有野心的項目。

您是否應該使用 Ajax？

Ajax是一種由一組技術(shù)構成的架構風(fēng)格。這些技術(shù)本身并沒(méi)有好壞之分；它們都是中立的。只有在某些組織能夠應用某種技術(shù)來(lái)解決特定的問(wèn)題或滿(mǎn)足特定的需求時(shí)，這種技術(shù)才會(huì )或多或少地有用。因此要回答 “我應該使用 Ajax 嗎？” 這個(gè)問(wèn)題，您必須評估自己的組織正在嘗試解決的問(wèn)題是什么，Ajax可以對您實(shí)現目標提供怎樣的幫助（還是根本就幫不上忙），以及您的組織是否具有項目成功所需要的恰當人員。

考慮采納選項的范圍

我們可能會(huì )納悶，“采納 Ajax” 到底是什么意思。要利用 Ajax，組織并不需要重新編寫(xiě)使用純 Ajax/REST 架構的程序。我建議您從一些小程序入手，逐漸積累一些經(jīng)驗和信心，而不是直接立即采用純粹的 Ajax/REST 架構。

采納 Ajax 可以意味著(zhù)完成一些輕量和細微的任務(wù) —— 可能是重新實(shí)現 Web應用程序的一個(gè)小特性，以使其更酷、更具響應性。Netflix 電影反饋特性就是這種輕量級風(fēng)格的一個(gè)例子。顧客可以通過(guò)點(diǎn)擊 1 到 5星來(lái)快速給電影評分。每次點(diǎn)擊會(huì )立即更新 它們的 Netflix 參數，并相應地調整推薦電影。

在采納的整個(gè)領(lǐng)域內，高端采納就是諸如 Google 的 Gmail 和 Maps 之類(lèi)的應用程序，它們已經(jīng)重新定義了 Web 應用程序開(kāi)發(fā)的當前發(fā)展水平。這些應用程序因其眾多的直觀(guān)交互特性、可視化效果和根據用戶(hù)操作和數據不斷調節用戶(hù)界面方面的能力而知名。

設想一下，如果您為自己的行業(yè)開(kāi)發(fā)一個(gè)像 Google Maps一樣精密的程序會(huì )接受到多少正面的反應，這非常有趣。但應該現實(shí)一點(diǎn)。Google 可能是世界上最出色的 Web 開(kāi)發(fā)組織，因此以它為基準來(lái)衡量Ajax的能力是非常危險的。不要忘記，Google（明智地）只有為黃金時(shí)間做好準備后才會(huì )發(fā)布自己的新應用程序，因此我們只看到了成功?？梢酝茰y，即使是Google 的天才們偶爾也會(huì )在應用 Ajax 時(shí)失敗，我們只是不知道這些失敗而已。

純 Ajax/REST 是一種新的架構風(fēng)格，相對于諸如 JSP（JavaServer? Page 技術(shù)）和 PHP 等較為成熟的Web 應用程序風(fēng)格來(lái)說(shuō)，它仍然很難實(shí)現。除非提供下一代的 Web 用戶(hù)經(jīng)驗是主要需求，而且還有世界級的 Web 開(kāi)發(fā)團隊，否則您的組織最好像Netflix 一樣最初 “小規模地采納 Ajax”，而不是像 Google 一樣 “大規模地采納 Ajax”。

評估 Ajax 能為您達成目標帶來(lái)怎樣的幫助

問(wèn)問(wèn)自己，Ajax 編程風(fēng)格有哪些特征使它對于您的應用程序的需求具有吸引力。您的公司正在尋找響應性更高的 UI能提供的生產(chǎn)力增長(cháng)點(diǎn)嗎？您希望部署一個(gè)高度動(dòng)態(tài)和個(gè)性化，又具備可伸縮性的應用程序嗎？對于您的目標客戶(hù)群來(lái)說(shuō)，“酷”會(huì )成為一種具有差異化優(yōu)勢的特性嗎？所有這一切都是合理的理由，還有些其他方面的理由。關(guān)鍵在于，您必須能夠找到一個(gè)合情合理的采納 Ajax的理由。下面是 Ajax 可以很好地實(shí)現的 3 種功能：

• 響應性更好的 UI。 在傳統的服務(wù)器端 Web 應用程序中，任何與服務(wù)器的交互都要求刷新頁(yè)面，這意味著(zhù)這中間需要 2 到 5 秒的延時(shí)，還要刷新整個(gè)頁(yè)面。Ajax 使用戶(hù)可以與服務(wù)器通過(guò) “fire and forget” 的交互方式來(lái)與服務(wù)器交互：用戶(hù)執行一個(gè)操作，系統可以在后臺處理該任務(wù)，同時(shí)用戶(hù)可以繼續處理其他任務(wù)。UI 只需要更新有新信息要顯示的部分即可，而不用重畫(huà)整個(gè)頁(yè)面。如果一切順利，Ajax 風(fēng)格的 UI 可以讓用戶(hù)實(shí)現并維護這種流程，從而提高用戶(hù)滿(mǎn)意度和生產(chǎn)力。
  
  
• 迷人。對于那些對外的應用程序和產(chǎn)品來(lái)說(shuō)，只實(shí)現需要實(shí)現的功能已不足以使之成為一種好產(chǎn)品。您的客戶(hù)現在 有著(zhù)太多的選擇。您需要一種產(chǎn)品來(lái)吸引用戶(hù)，并使他們?yōu)橹?zhù)迷。就像諺語(yǔ)所說(shuō)的那樣，“性感就是一種特質(zhì)”。這并不是說(shuō)需要將開(kāi)發(fā)人員可以想像到的所有鈴 聲和鐘聲都包含在其中 —— 看一下最低配置設計的 iPod 是如何擊敗那些具有 10 倍控制功能的便攜式音樂(lè )播放器就能明白這個(gè)道理。問(wèn)題的關(guān)鍵是提供一種包含眾多細微特性的一流設計，幫助用戶(hù)以一種輕松愉快的方式來(lái)完成自己要做的事情。

  Gmail 是一個(gè)很好的例子。從外表上來(lái)說(shuō)，Gmail 只不過(guò)是另外一個(gè)基于 Web 的 e-mail 應用程序，這種技術(shù)已經(jīng)存在 10 年之久了。但是 Gmail 使用 Ajax 做了一些正確的事情。您之前曾經(jīng)由于意外地關(guān)閉瀏覽器而丟失過(guò)未發(fā)送的 e-mail 消息嗎？Gmail 開(kāi)發(fā)人員仔細考慮了這個(gè)問(wèn)題，通過(guò)精心設計，差不多每分鐘都會(huì )將未發(fā)送的消息的一份副本保存到草稿文件夾中。每次都要查找隨時(shí)都會(huì )使用的 e-mail 地址是不是很煩呢？Gmail 開(kāi)發(fā)人員仔細考慮了這個(gè)問(wèn)題，基于以前發(fā)送的 e-mail 消息提供了一種精心設計的地址補全算法。

  “迷人” 對于外部及商業(yè)應用程序來(lái)說(shuō)非常重要，但是對于內部業(yè)務(wù)應用程序來(lái)說(shuō)則沒(méi)這么重要。一切取決于環(huán)境。

  
  
• 不犧牲可伸縮性的個(gè)性化。在過(guò)去的十五年中，隨著(zhù)傳統服務(wù)器端應用程序朝著(zhù)更加動(dòng)態(tài)化和個(gè)性化的方向不斷發(fā)展，開(kāi)發(fā)人員和中間件也越來(lái)越多地向在服務(wù)器端存儲大量的會(huì )話(huà)狀態(tài)而努力。這種方式會(huì )推動(dòng)個(gè)性化的發(fā)展，但對于可伸縮性來(lái)說(shuō)卻是個(gè)噩耗。正如在 第 1 部分 中所介紹的一樣，Ajax 應用程序通常都是將會(huì )話(huà)狀態(tài)保存到客戶(hù)機端，并通過(guò)無(wú)狀態(tài)的服務(wù)與服務(wù)器進(jìn)行交互，這樣可以獲得動(dòng)態(tài)性和個(gè)性化都非常好的 Web 應用程序，而不會(huì )犧牲可伸縮性。

決斷

這三方面的收益會(huì )幫助您的組織取得成功嗎？如果不行，那 Ajax又提供了哪些其他特別的優(yōu)勢來(lái)為您的組織的成功貢獻力量呢？如果您現在還找不到有說(shuō)服力的具體理由來(lái)采用 Ajax，那么我建議您暫時(shí)先不要考慮Ajax 了，直到找到這樣一個(gè)理由為止。如果您的確有這樣的理由，那么請繼續閱讀本文。

回頁(yè)首

使用 Ajax 獲得成功

您已經(jīng)確定 Ajax 可以為組織帶來(lái)一些獨特的價(jià)值，這可以證明為采用這種新興技術(shù)而冒的風(fēng)險是值得的。本節將討論如何將 Ajax技術(shù)成功整合到我們的應用程序和軟件開(kāi)發(fā)過(guò)程中。在下一節中，我們將討論在 “大規模采納 Ajax” 技術(shù)開(kāi)發(fā)時(shí)所需考慮的一些特殊事項。

從小處入手，獲取經(jīng)驗，建立信心

對于一種有用的新興技術(shù)，沒(méi)有什么打擊能比某個(gè)項目試圖使用這種技術(shù)但卻在眾人的矚目下失敗更嚴重了。這通常是由于尚不具備足夠的技能，卻一次過(guò)快地嘗試過(guò)多新東西而引起的。但是現在很難找到具有豐富 Ajax 開(kāi)發(fā)經(jīng)驗的開(kāi)發(fā)人員；這種技術(shù)還太年輕。

為了解決這個(gè)問(wèn)題，開(kāi)發(fā)組織應該通過(guò)在真正的項目上實(shí)施 Ajax 來(lái)逐漸積累使用 Ajax的經(jīng)驗，但是先不要在關(guān)鍵特性上嘗試這種技術(shù)。集中精力先將一些小特性部署到真實(shí)的世界中。從錯誤中不斷學(xué)習和調整。如果試圖過(guò)早地邁出一大步，那么就會(huì )給項目帶來(lái)太多風(fēng)險。這一步邁得越大，經(jīng)過(guò)一個(gè)完整的設計/開(kāi)發(fā)/測試/部署周期所需要的時(shí)間也就越長(cháng)，而這是獲取實(shí)踐經(jīng)驗的關(guān)鍵。

這個(gè)建議更適用于那些希望 “小規模嘗試 Ajax” 的組織；不過(guò)對于那些希望 “大規模采納 Ajax” 技術(shù)的組織來(lái)說(shuō)，他們也可以通過(guò)循環(huán)往復的開(kāi)發(fā)方式從小處入手，正如我們在 “大規模采納 Ajax 技術(shù)”的特殊考慮事項 一節中討論的一樣。

找到適當的人來(lái)設計 UI 和開(kāi)發(fā)服務(wù)

設想一下，您的 Web 開(kāi)發(fā)人員團隊中有些人在過(guò)去 10 年中已成功交付了很多 PHP、Java 或 .NET 服務(wù)器端 Web應用程序，如果他們可以順利成長(cháng)為 Ajax 專(zhuān)家，那的確非常令人興奮，但是實(shí)際情況可能并非如此。盡管我們仍然在 Web 開(kāi)發(fā)這個(gè)領(lǐng)域內工作，但是Ajax 架構風(fēng)格和支持技術(shù)需要開(kāi)發(fā)人員忘卻舊知識，重新學(xué)習新語(yǔ)言和新模式。這種轉型的確 是可能的，不過(guò)需要花費一些時(shí)間。

在傳統的服務(wù)器端 Web 開(kāi)發(fā)中，您需要處理鏈接的點(diǎn)擊和表單的提交，并使用一個(gè)完整的 HTML頁(yè)面進(jìn)行響應。通常一個(gè)工作流都會(huì )跨越很多頁(yè)面，因此服務(wù)器端應用程序邏輯必須維護與瀏覽器之間的會(huì )話(huà)。服務(wù)器必須記住整個(gè)應用程序一次次的點(diǎn)擊，這樣在用戶(hù)與 Web 應用程序進(jìn)行交互時(shí)，才能提供無(wú)縫的工作流。在 Ajax 世界中，我們從這個(gè) “綠色屏幕”模型轉換成了一個(gè)真正的客戶(hù)機-服務(wù)器模型，其中客戶(hù)機是有狀態(tài)的，而且是動(dòng)態(tài)的，服務(wù)器只需要負責提供原子的無(wú)狀態(tài)服務(wù)即可。這種新編程風(fēng)格要求具備客戶(hù)端和服務(wù)器端方面的不同技巧。

在客戶(hù)端，我們需要那些在長(cháng)于 CSS、JavaScript 和文檔對象模型（DOM）編程的開(kāi)發(fā)人員。問(wèn)題是大部分開(kāi)發(fā)組織都宣稱(chēng)“我們具有使用 JavaScript 和 CSS 的經(jīng)驗”，但那往往是一些微不足道的功能，例如修飾文本和在客戶(hù)端進(jìn)行表單的驗證。認為具有這點(diǎn)JavaScript/CSS 經(jīng)驗的服務(wù)器端 Web 開(kāi)發(fā)人員可以勝任大規模 Ajax 應用程序的工作就像是認為會(huì )開(kāi)車(chē)的人就有資格Daytona 500 賽事一樣荒唐。

這也是為什么從小處入手如此重要的另外一個(gè)原因。我們的 Web 開(kāi)發(fā)人員現在可能還不具備創(chuàng )建 Gmail 這么重量級的 Ajax應用程序所需要的技能和經(jīng)驗，不過(guò)他們應該可以在現有服務(wù)器端 Web 應用程序上實(shí)現一些小規模的改進(jìn)。隨著(zhù)時(shí)間和經(jīng)驗的積累，他們逐漸就可以使用Ajax 來(lái)實(shí)現更加復雜的場(chǎng)景了。

在服務(wù)器端，Ajax代表了一種轉換，因為我們可以將一些不引人注目的會(huì )話(huà)管理和工作流狀態(tài)從服務(wù)器上移開(kāi)了。一旦我們積累了足夠的經(jīng)驗，Ajax 風(fēng)格的“有狀態(tài)客戶(hù)機/無(wú)狀態(tài)服務(wù)器” 更容易理解和管理，但是這種架構風(fēng)格的改變需要一些新的技能。我們的服務(wù)開(kāi)發(fā)人員應該很好地理解 HTTP 協(xié)議，了解TEST 架構風(fēng)格的知識，并且具備開(kāi)發(fā)分布式服務(wù)的經(jīng)驗，例如遠程方法調用（RMI）和遠程過(guò)程調用（RPC）。盡管 REST 架構風(fēng)格與 RPC有一些根本性的區別，但是它們所涉及的一些非功能性的基本準則（邊界安全性、網(wǎng)絡(luò )延遲和非可靠性）都是通用的。

使用框架

DOM、CSS 和 XMLHttpRequest（XHR）“標準”與瀏覽器有很大的不同。那些不希望選擇現有框架來(lái)解決這些差異的開(kāi)發(fā)人員可能會(huì )花費大量意料之外的時(shí)間來(lái)編寫(xiě)自己的信息管道代碼，以便對瀏覽器間的不一致性進(jìn)行規范化。您的信息管道代碼的品質(zhì)在達到目前可用框架已達到的品質(zhì)之前，需要有很長(cháng)一段時(shí)間。一種可行的框架是開(kāi)源的 Dojo 工具包（請參看 參考資料）。

學(xué)習和使用工具

開(kāi)發(fā) Ajax 應用程序涉及兩種截然不同的行為：使用 HTML/JavaScript/CSS/DOM 實(shí)現 UI和應用程序邏輯，以及使用早已建立的服務(wù)器端平臺（例如 PHP、J2EE 和.NET）來(lái)實(shí)現服務(wù)器邏輯。在服務(wù)器端，可以使用以前一直使用的工具。在客戶(hù)端，則需要學(xué)習使用一些新工具。對于希望支持的每個(gè)瀏覽器，都可能都需要一個(gè)不同的 Ajax 工具包。這里有一個(gè)通用工具功能的列表（請參看 參考資料 中支持兩種最流行的 Web 瀏覽器 —— Microsoft Internet Explorer 和 Mozilla Firefox 的工具的鏈接）：

• 編寫(xiě)代碼：編輯器和 IDE。 在客戶(hù)機端 Ajax 開(kāi)發(fā)中，我們需要編寫(xiě) HTML、CSS 和 JavaScript 文件的組合。代碼編輯器可以通過(guò)語(yǔ)法高亮顯示、語(yǔ)法錯誤檢查以及代碼補全功能來(lái)提高我們的生產(chǎn)效率。
  
  
• 檢查結構：DOM 檢查器。由于 Ajax Web 頁(yè)面的很多可視化結構都是在用戶(hù)與頁(yè)面進(jìn)行交互時(shí)動(dòng)態(tài)創(chuàng )建的，因此為了探索頁(yè)面實(shí)際的結構，僅僅查看源代碼并不能滿(mǎn)足要求。源代碼很可能與我們所看到的 UI 根本就沒(méi)有任何相似之處。我們需要在與頁(yè)面進(jìn)行交互時(shí)對 DOM 結構進(jìn)行檢查。DOM 查看器有一個(gè)很好的補足特性是 “實(shí)際源代碼” 檢查器，它能對 DOM 當前狀態(tài)的 HTML 源代碼進(jìn)行反向工程，這樣就可以為那些習慣查看 HTML 源代碼的開(kāi)發(fā)人員提供一種直觀(guān)的手段來(lái)了解頁(yè)面的內容。
  
  
• 檢查行為：JavaScript 調試器。在編寫(xiě)一些小 JavaScript 腳本來(lái)驗證表單或提供少量交互能力時(shí)，大部分開(kāi)發(fā)人員都可以使用簡(jiǎn)單的 alert 語(yǔ)句來(lái)定位問(wèn)題所在。但是當您開(kāi)始進(jìn)行大規模 Ajax 開(kāi)發(fā)時(shí)，就需要為希望支持的每種 Web 瀏覽器來(lái)尋找并學(xué)習一種 JavaScript 調試器。
  
  
• 檢查客戶(hù)機-服務(wù)器交互：XHR 監視器。 Ajax 工具包最后一個(gè)重要的工具是 XmlHttpRequest（XHR）監視器。XHR 是一個(gè) JavaScript 對象，它可以與服務(wù)器進(jìn)行 Ajax 風(fēng)格的遠程通信。XHR 監視器使我們可以對請求/響應對進(jìn)行監視，包括它們的頭和內容。

在實(shí)際環(huán)境中進(jìn)行測試

文檔中也明確提到，如果沒(méi)有開(kāi)發(fā)人員的努力，Ajax 會(huì )破壞我們對 Web 站點(diǎn)的一些基本期望：例如，后退按鈕、書(shū)簽或瀏覽器的“加載” 控件都有可能無(wú)法正常工作。我所給出的 “從小處入手” 的建議在這里也能提供一些幫助。只要您只使用 Ajax來(lái)實(shí)現一些增量新特性，它們只會(huì )更新頁(yè)面狀態(tài)，而不會(huì )對導航或工作流造成影響，那么后退按鈕和書(shū)簽都不會(huì )有任何問(wèn)題。但是加載時(shí)間可能會(huì )成為一個(gè)問(wèn)題，尤其是當我們只在本地開(kāi)發(fā)環(huán)境上進(jìn)行測試時(shí)更是如此，此時(shí)網(wǎng)絡(luò )延時(shí)并不會(huì )成為太大的制約因素。

考慮一下：在傳統的 Web 應用程序中，當用戶(hù)點(diǎn)擊一個(gè)鏈接或提交一個(gè)表單時(shí)，即使后續頁(yè)面的加載花費了 10 秒鐘，它們也會(huì )從瀏覽器的“加載” 控件中看到即時(shí)反饋。在 Ajax 應用程序中，點(diǎn)擊一個(gè)可以觸發(fā) XHR 請求的控件并不會(huì )激活 “加載”控件。只在本地開(kāi)發(fā)環(huán)境上進(jìn)行測試的危險在于：HTTP 請求、響應和后續的 UI 更新看起來(lái)似乎都是即時(shí)發(fā)生的，這造成了缺乏瀏覽器 “加載”反饋機制貌似也不是什么問(wèn)題的假象。但在產(chǎn)品環(huán)境中，用戶(hù)距離服務(wù)器可能會(huì )有成百上千里遠，缺乏這種反饋機制就可能會(huì )產(chǎn)生困擾并挫敗他們的信心。用戶(hù)可能會(huì )納悶：“我點(diǎn)中這個(gè)控件了嗎？讓我再點(diǎn)一下看看。仍然什么都沒(méi)有！”

遺憾的是，即使您在工程方面作出了最大的努力，網(wǎng)絡(luò )延遲依然會(huì )存在，因此我們必須接受這個(gè)事實(shí)。假設有時(shí)用戶(hù)點(diǎn)擊控件和服務(wù)器的響應到達之間存在一些時(shí)間的滯后。當用戶(hù)作出某種表示發(fā)起一個(gè)遠程調用時(shí)，瀏覽器會(huì )提供一條即時(shí)反饋，說(shuō)明它已經(jīng)看到了用戶(hù)的這個(gè)表示。臨時(shí)禁用控件或顯示一條消息說(shuō)明正在發(fā)生什么，直到接收到服務(wù)器的響應并使用這些信息來(lái)更新 UI 之后才刪除這條消息。網(wǎng)絡(luò )調用是瓶頸所在；編寫(xiě)需要執行很長(cháng)時(shí)間的JavaScript 代碼還比較困難。

問(wèn)題的關(guān)鍵是我們需要在真實(shí)的環(huán)境中進(jìn)行測試，此時(shí)這些可用性問(wèn)題都很容易發(fā)現。問(wèn)題發(fā)現得越早，相應進(jìn)行響應的時(shí)間也就越早。

在真實(shí)環(huán)境中進(jìn)行測試的另外一個(gè)方面是要確保在需要支持的每種瀏覽器的每個(gè)版本上進(jìn)行所有的功能測試。例如，如果您聲稱(chēng)要支持Firefox 1.5 和 2.0 以及 Internet Explorer 6 和7，那就需要在這些瀏覽器上持續進(jìn)行測試?；蛟S這是顯而易見(jiàn)的道理，但開(kāi)發(fā)人員卻很容易陷入一些懷習慣：只在自己喜歡的瀏覽器上進(jìn)行開(kāi)發(fā)和測試，以后在其他瀏覽器上發(fā)現問(wèn)題時(shí)就會(huì )需要重新修整自己的代碼。

回頁(yè)首

“大規模采納 Ajax 技術(shù)” 的特殊考慮事項

盡管我們已經(jīng)建議您不要去嘗試創(chuàng )建像 Gmail 或 Google Maps 那樣龐大的 Ajax應用程序，但是有些業(yè)務(wù)或者工程代理可能會(huì )迫使您那樣做。我們的第一反應是：不要這樣做 —— 從小處入手，不但積累經(jīng)驗。但是如果立即就要構建一個(gè)純Ajax 應用程序，就請繼續閱讀本文。

關(guān)于人員

您的開(kāi)發(fā)團隊現在就更加重要了，因為您不是簡(jiǎn)單地使用新技術(shù)來(lái)擴展久經(jīng)驗證的架構，而是要采用一個(gè)全新的架構。您的團隊雖然在 Ajax 方面的經(jīng)驗很少，但需要作出一些重要的決策 —— 這些設計決策可能會(huì )導致可怕的錯誤后果。

您需要一些在 JavaScript/DOM 和 CSS 方面具有豐富經(jīng)驗的成員。如果沒(méi)有豐富 JavaScript經(jīng)驗的人，就要尋找一些在其他腳本編程語(yǔ)言（例如 Perl、Python 或 Ruby）方面具有豐富經(jīng)驗的人。Lisp 或 Scheme等功能編程語(yǔ)言方面的經(jīng)驗也會(huì )很有幫助，但經(jīng)驗豐富的 Lisp/Scheme 程序員可能比熟練的 JavaScript 程序員還要稀少。

不要低估良好的 CSS 對應用程序品質(zhì)的重要影響。缺乏對 CSS 的深入理解可能會(huì )導致一些原本不必那樣糟糕、難以維護的代碼，這會(huì )使得首次或再次重寫(xiě)代碼更加困難。

重新編寫(xiě)？你說(shuō)什么？

規劃重新編寫(xiě) …… 至少兩次

每當您進(jìn)行新領(lǐng)域的開(kāi)發(fā)工作時(shí)，第一次就可以做出正確決策的可能性很小。您可能會(huì )腳步蹣跚地弄出一些難經(jīng)推敲、滿(mǎn)是缺陷的設計，也可以先從小處著(zhù)手，然后隨著(zhù)不斷學(xué)習新知識并獲得哪些能做哪些不能做的經(jīng)驗之后，再不斷更新設計。

Ajax 提出了一項獨特的挑戰，因為用戶(hù)經(jīng)驗和底層架構模式與服務(wù)器端的對應部分有著(zhù)很大的區別。在您的 UI中，可能會(huì )發(fā)現一些細微但有持續性影響的瑕疵：后退按鈕并不能像如期工作，當用戶(hù)調用遠程操作時(shí)沒(méi)有太多反饋，等等。遺憾的是，在具備這方面的經(jīng)驗并明白必須修改設計中的哪些地方以便修復這些問(wèn)題之前，您很難為這些問(wèn)題設計解決方案。

希望重新編寫(xiě)自己的應用程序的另一原因是在您獲得使用 JavaScript/DOM 和 CSS經(jīng)驗的同時(shí)，您會(huì )發(fā)現一些新術(shù)語(yǔ)和模式，它們可以帶來(lái)更加簡(jiǎn)明、可讀性和可維護性更好的代碼。另外，隨著(zhù)您編寫(xiě)的代碼越來(lái)越多，您就可以開(kāi)始著(zhù)手解決一些通用的問(wèn)題，盡管這些問(wèn)題的通用性還不足以進(jìn)入第三方的框架，但卻足以放入我們自己的庫中，而不是到處散落于頂層的代碼中。重構原來(lái)的代碼從而使用新的庫代碼，這樣從長(cháng)遠來(lái)看是值得的，不過(guò)需要花費一些時(shí)間，而且這種活動(dòng)需要不斷進(jìn)行下去。您會(huì )發(fā)現，自己逐漸進(jìn)入了框架領(lǐng)域，這里又有一些自己的問(wèn)題集。

謹慎進(jìn)入框架領(lǐng)域

隨著(zhù)您在大規模應用程序中取得不斷進(jìn)展，就會(huì )發(fā)現，很多通用應用程序服務(wù)都不是由純粹的 JavaScript/DOM/CSS 或全新的Ajax 框架（例如 Dojo 和Prototype）提供的。您要嘗試創(chuàng )建自己的框架級的代碼來(lái)簡(jiǎn)化新應用程序級功能的創(chuàng )建。這通常不是什么壞事；大部分最好的開(kāi)發(fā)框架（例如 Rubyon Rails）都已經(jīng)從具體的應用程序需求中提取出來(lái)了。但是務(wù)必謹慎；我已經(jīng)警告過(guò)，在小范圍內采納 Ajax 是可行的，但是大規模采納Ajax 會(huì )非常困難 —— 難度可能會(huì )高出一個(gè)數量級。支持大規模采納 Ajax 的設計框架級技術(shù)的難度又會(huì )高出一個(gè)數量級，尤其是在您剛剛接觸Ajax 技術(shù)領(lǐng)域時(shí)更是如此。

框架代碼引入了更多層次的抽象和間接調用，這使得代碼路徑很難理解。經(jīng)驗之一是盡可能在具體的應用程序層進(jìn)行工作，只有在應用程序中至少有 3 個(gè)部分都可能會(huì )使用代碼所提供的功能時(shí)，才考慮將部分代碼移動(dòng)到一個(gè)框架和可重用的庫中。

迭代，迭代，迭代

新領(lǐng)域開(kāi)發(fā)中的一個(gè)主要的反模式就：在最初設計和實(shí)現一個(gè)真正的用戶(hù)可用并可提供反饋意見(jiàn)的小產(chǎn)品之間需要花費太多時(shí)間。因此，在您著(zhù)手實(shí)現大型的新 Ajax 應用程序之前，應該先在幾周之內提供一個(gè)基本可以工作的展示模型，以便讓用戶(hù)開(kāi)始提供反饋。UI可能還非常原始，代碼也許并不完美，但如果您在讓用戶(hù)體驗新應用程序之前先花費 6 個(gè)月的時(shí)間進(jìn)行開(kāi)發(fā)，結果也是這樣；惟一的區別就是，要丟棄的代碼和UI 都要多上 10 倍。

您需要在很長(cháng)的設計周期中加速循環(huán)過(guò)程，使真正的用戶(hù)一直在一個(gè)仿真產(chǎn)品條件的環(huán)境中體驗產(chǎn)品。這種方法的最高境界是搭建一個(gè)測試服務(wù)器，開(kāi)發(fā)人員每隔幾天就在上面更新代碼，這樣用戶(hù)和項目主管就可以體驗新產(chǎn)品并提供反饋了。

回頁(yè)首

結束語(yǔ)

采納 Ajax技術(shù)最大的風(fēng)險是目前業(yè)界普遍缺乏實(shí)踐經(jīng)驗。由于這個(gè)原因，我建議您從小處入手，讓開(kāi)發(fā)團隊開(kāi)始積累經(jīng)驗并培養自信，這樣就不會(huì )給項目造成太大的風(fēng)險。如果您決定，現在就集中精力投身于純 Ajax 設計，那么請現實(shí)一點(diǎn)，應該理解，這種方式的成功幾率很低。除非您擁有世界級的 Web開(kāi)發(fā)團隊，以及可以支持迭代開(kāi)發(fā)和實(shí)驗的開(kāi)發(fā)組織，否則很可能要失敗。

不過(guò)隨著(zhù)時(shí)間的推移，事情會(huì )變得越來(lái)越簡(jiǎn)單，風(fēng)險也會(huì )越來(lái)越低，因為越來(lái)越多的實(shí)踐者會(huì )不斷積累經(jīng)驗，新的框架、工具和最佳實(shí)踐也會(huì )不斷涌現。Ajax 會(huì )變得更加安全，也會(huì )成為更普及的技術(shù) ……. 不過(guò)這個(gè)階段可能不會(huì )在短時(shí)間內到來(lái)。

致謝

非常感謝 Rational 組的同事 Erich Gamma、Grady Booch、Josh Staiger、Pat Mueller 和 Scott Rich 與我分享他們的觀(guān)點(diǎn)并為本文提供反饋。

參考資料

學(xué)習

• “Ajax 和 REST, 第 1 部分”（Bill Higgins， developerWorks，2006 年 10 月）：學(xué)習 Ajax/REST 架構風(fēng)格為 Web 應用程序所帶來(lái)的收益。
  
  
• “Debug JavaScript in Internet Explorer”：有關(guān) Microsoft Script Editor 的 how-to 信息，這是隨 Microsoft Office 一起發(fā)行的一個(gè)附件。
  
  
• Ajax Design Patterns （Michael Mahemoff，O'Reilly， 2006）：Mahemoff 編寫(xiě)的有關(guān) Ajax 測試的一章內容很好地總結了 2006 年 Ajax 單元測試的狀況。
  
  
• 請訪(fǎng)問(wèn) 作者的 blog。
  
  
• Ajax 資源中心：這是 developerWorks 所有關(guān)于 Ajax 的資源的中心。
  
  

獲得產(chǎn)品和技術(shù)

• Dojo Toolkit：Dojo 是一個(gè)開(kāi)源的 Ajax 框架，它有一些庫來(lái)幫助實(shí)現模塊管理、事件處理和遠程通信。Dojo 的包管理系統讓我們可以簡(jiǎn)化編譯和部署定制 Ajax 代碼以及所需 Dojo 部分的過(guò)程。
  
  
• Aptana：Aptana 是一個(gè)開(kāi)源的以 JavaScript 為基礎的 IDE，它針對很多平臺具有很多不同的版本。
  
  
• Eclipse Ajax Toolkit Framework（ATF）：ATF 提供了一個(gè)集成的 Ajax 工具包，包括 DOM 檢查器，XHR 監視器，以及 “查看實(shí)際源代碼” 的功能。
  
  
• FireBug：FireBug 與 Firefox 相集成，提供了錯誤控制臺、DOM 檢查器和 XHR 監視器。它也包含 “查看實(shí)際源代碼” 的功能。
  
  
• Venkman Debugger：一個(gè)為 Firefox 編寫(xiě)的 JavaScript 調試器。
  
  
• Internet Explorer Developer Toolbar：為 IE 設計的 DOM 監視器和其他工具。
  
  
• LiveHTTPHeaders 和 TamperData：為 Firefox/Mozilla 設計的 XHR 監視器。
  
  
• Fiddler 和 HTTP Analyzer：為 Internet Explorer 設計的 XHR 監視器。
  
  

討論

• Ajax 論壇：如果有關(guān)于 Ajax 開(kāi)發(fā)的問(wèn)題，那么這個(gè)由 Jack Herrington 維護的論壇可給您提供幫助。