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 是一種由一組技術(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”。
問(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 種功能：
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)境。
這三方面的收益會(huì )幫助您的組織取得成功嗎？如果不行，那 Ajax 又提供了哪些其他特別的優(yōu)勢來(lái)為您的組織的成功貢獻力量呢？如果您現在還找不到有說(shuō)服力的具體理由來(lái)采用 Ajax，那么我建議您暫時(shí)先不要考慮 Ajax 了，直到找到這樣一個(gè)理由為止。如果您的確有這樣的理由，那么請繼續閱讀本文。
 |
|
您已經(jīng)確定 Ajax 可以為組織帶來(lái)一些獨特的價(jià)值，這可以證明為采用這種新興技術(shù)而冒的風(fēng)險是值得的。本節將討論如何將 Ajax 技術(shù)成功整合到我們的應用程序和軟件開(kāi)發(fā)過(guò)程中。在下一節中，我們將討論在 “大規模采納 Ajax” 技術(shù)開(kāi)發(fā)時(shí)所需考慮的一些特殊事項。
對于一種有用的新興技術(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 工具包（請參看 參考資料）。
開(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 的工具的鏈接）：
 |
|
alert 語(yǔ)句來(lái)定位問(wèn)題所在。但是當您開(kāi)始進(jìn)行大規模 Ajax 開(kāi)發(fā)時(shí)，就需要為希望支持的每種 Web 瀏覽器來(lái)尋找并學(xué)習一種 JavaScript 調試器。XmlHttpRequest（XHR）監視器。XHR 是一個(gè) JavaScript 對象，它可以與服務(wù)器進(jìn)行 Ajax 風(fēng)格的遠程通信。XHR 監視器使我們可以對請求/響應對進(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ì )需要重新修整自己的代碼。
|
|
盡管我們已經(jīng)建議您不要去嘗試創(chuàng )建像 Gmail 或 Google Maps 那樣龐大的 Ajax 應用程序，但是有些業(yè)務(wù)或者工程代理可能會(huì )迫使您那樣做。我們的第一反應是：不要這樣做 —— 從小處入手，不但積累經(jīng)驗。但是如果立即就要構建一個(gè)純 Ajax 應用程序，就請繼續閱讀本文。
您的開(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ō)什么？
每當您進(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)題集。
隨著(zhù)您在大規模應用程序中取得不斷進(jìn)展，就會(huì )發(fā)現，很多通用應用程序服務(wù)都不是由純粹的 JavaScript/DOM/CSS 或全新的 Ajax 框架（例如 Dojo 和 Prototype）提供的。您要嘗試創(chuàng )建自己的框架級的代碼來(lái)簡(jiǎn)化新應用程序級功能的創(chuàng )建。這通常不是什么壞事；大部分最好的開(kāi)發(fā)框架（例如 Ruby on 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)品并提供反饋了。
|
|
采納 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)。
聯(lián)系客服
