AJAX 開發的兩種不同的方法

最近幾年Ajax應用程式開發出現了兩種截然不同的方法,每一種方法都對以前的結構模型進行擴充.由於兩種方法性質看起來是不同的,所以在實際應用程式的開發中應選擇其中一種. 

　　當我們第一次聽到Ajax這個術語的時候,我們的第一反應可能就是其較高的Web頁面互動性.至少在JavaScript中的Web應用程式部分必要的代碼提供互動性,雖然在Ajax應用程式意義方面都有一致的意見,但對於開發人員如何與JavaScript進行互動或者如何在用戶端與伺服器之間分配顯示邏輯有一些分歧. 

　　最近幾個月,在Artima中報道了幾個Java中心胖用戶端架構,目的在於完全的隱藏開發人員與JavaScript進行互動.這些架構將JavaScript整合到了JSF組件中,從而作為一個工具來處理JavaScript,其中的細節對開發人員來說是隱藏的.利用JSF伺服器端表現模型的優勢,基於Ajax的JSF在用戶端轉譯出組件的狀態. 

　　相反,Ajax在個別的用戶端組件工具包中有優勢,像Dojo或者 Prototype不僅將JavaScript呈現給使用者,而且對開發人員來說開發頁面類型的應用程式更加容易.例如Dojo工具包提供許多API,這些API類比J2SE API的重要部分,像收集和驗證器.另外UI工具,這樣的應用程式將不僅起顯示邏輯的作用,甚至一些在用戶端上商務邏輯,這些商務邏輯將會使用JavaScript來進行編碼.與服務端進行互動將會被限制在這樣的情況,即用戶端應用程式必須與外部的資源進行互動,例如,提取資料到用戶端或者儲存使用者的變化到資料中去. 

　　因為基於Ajax的JSF方法執行在伺服器端的展現層並且將Ajax的特性融進到組件中去,這看起來像瘦用戶端的一個擴充,並且是傳統的Web應用程式的直接派生,這種方法的細微的共同點是Sun Ray瘦用戶端裝置,這種瘦用戶端裝置在伺服器端顯示案頭圖片,用戶端處理至多一個專門的顯示.第二種方法是一個用戶端-伺服器的擴充,以至於在用戶端和伺服器之間顯示應用程式的邏輯.在Ajax中,用戶端是一個可程式化的Web瀏覽器. 

　　這兩種犯法都是建立在良好的實踐基礎上的,在應用程式開發中是不同的體系,瘦用戶端涉及到在瀏覽器中JavaScript執行的不相容性,他們很少涉及到是否瘦用戶端模型是首選的即使所有的瀏覽器能夠很好的顯示JavaScript. 

　　然而,JavaScript在開發邏輯方面仍然是比較困難的,在一個新的版本, EcmaScript 4,提供了一個完全的物件導向的語言,因為它是相當標準的,瀏覽器執行將還算是相容.另外用戶端類庫也已經掩飾了瀏覽器的大部分不相容性. 

　　用戶端支援者認為他們的方法能夠更好的使用本機電腦資源,這樣也導致在應用程式中能取代傳統的傳統型應用程式.即使沒有一個持久的網路連接. 

　　有經驗的認為每一個方法都有其利弊,如果你開發一個全新的胖用戶端應用程式,就不得不選擇或者是瘦用戶端或者是用戶端-伺服器模型.