開(kāi)發(fā)Ajax應用面(miàn)臨的問題及解決方案

對(duì)程序員而言，開(kāi)發(fā)Ajax應用頭痛的問題莫過(guò)于以下幾點：

浏覽器的兼容性問題

Ajax在本質上是一個浏覽器端的技術，首先面(miàn)臨無可避免的第一個問題即是浏覽器的兼容性問題。

各家浏覽器對(duì)于JavaScript／DOM／CSS的支持總有部分不太相同或是有Bug，甚至同一浏覽器的各個版本間對(duì)于JavaScript／DOM／CSS的支持也有可能(néng)部分不一樣(yàng)。這(zhè)導緻程序員在寫Ajax應用時花大部分的時間在調試浏覽器的兼容性而非在應用程序本身。因此，目前大部分的Ajax鏈接庫或開(kāi)發(fā)框架大多以js鏈接庫的形式存在，以定義更高階的JavaScript API 、JavaScript對(duì)象（模闆）、或者JavaScript Widgets來解決此問題。如prototype.js。

業務邏輯分散

Ajax技術之主要目的在于局部交換客戶端及服務器之間的數據。如同傳統之主從架構，無可避免的會有部分的業務邏輯會實現在客戶端，或部分在客戶端部分在服務器。由于業務邏輯可能(néng)分散在客戶端及服務器，且以不同之程序語言實現，這(zhè)導緻Ajax應用程序極難維護。如有用戶接口或業務邏輯之更動需求，再加上前一個JavaScript/DOM/CSS之兼容性問題，Ajax應用往往變成(chéng)程序員的夢魇。針對(duì)業務邏輯分散的問題，Ajax開(kāi)發(fā)框架大緻可分爲兩(liǎng)類：

將(jiāng)業務邏輯及表現層放在浏覽器，數據層放在服務器：因爲所有的程序以JavaScript執行在客戶端，隻有需要數據時才向(xiàng)服務器要求服務，此法又稱爲胖客戶端（fat client）架構。服務器在此架構下通常僅用于提供及儲存數據。此法的好(hǎo)處在于程序員可以充分利用JavaScript搭配業務邏輯來做出特殊的用戶接口，以符合終端用戶的要求。但是問題也不少，主因在

第一，JavaScript語言本身之能(néng)力可能(néng)不足以處理複雜的業務邏輯。

第二，JavaScript的執行效能(néng)一向(xiàng)不好(hǎo)。

第三，JavaScript訪問服務器數據，仍需适當的服務器端程序之配合。第四，浏覽器兼容性的問題又出現。

有些Ajax開(kāi)發(fā)框架如DWR企圖以自動生成(chéng)JavaScript之方式來避免兼容的問題，并開(kāi)立通道(dào)使得JavaScript

可以直接調用服務器端的Java程序來簡化數據的訪問。但是前述第一及第二兩(liǎng)個問題仍然存在，程序員必須費相當的力氣才能(néng)達到應用程序之規格要求，或可能(néng)根本無法達到要求。

將(jiāng)表現層、業務邏輯、及數據層放在服務器，浏覽器僅有用戶接口引擎（User Interface engine）；

此法又稱爲瘦客戶端（thin client）架構，或中心服務器（server-centric）架構。浏覽器的用戶接口引擎僅用于反映服務器的表現層以及傳達用戶的輸入回到服務器的表現層。由浏覽器所觸發(fā)之事(shì)件亦送回服務器處理，根據業務邏輯來更新表現層，然後(hòu)反映回浏覽器。因爲所有應用程序完全在服務器執行，數據及表現層皆可直接訪問，程序員隻需使用服務器端相對(duì)較成(chéng)熟之程序語言（如Java語言）即可，不需再學(xué)習JavaScript/DOM/CSS，在開(kāi)發(fā)應用程序時相對(duì)容易。缺點在于用戶接口引擎以及表現層通常以标準組件的形式存在，如需要特殊組件（用戶接口）時，往往須待原框架之開(kāi)發(fā)者提供，緩不濟急。如開(kāi)源碼Ajax開(kāi)發(fā)框架ZK目前支持XUL及XHTML組件，尚無XAML之支持。

多進(jìn)程或多線程的競争問題

Ajax是以異步的方式向(xiàng)服務器提交需求。對(duì)服務器而言，其與傳統的提交窗體需求并無不同，而且由于是以異步之方式提交，如果同時有多個Ajax需求及窗體提交需求，將(jiāng)無法保證哪一個需求先獲得服務器的響應。這(zhè)會造成(chéng)應用程序典型的多進(jìn)程（process）或多線程（thread）的競争（racing）問題。程序員因此必須自行處理或在JavaScript裡(lǐ)面(miàn)動手腳以避免這(zhè)類競争問題的發(fā)生（如Ajax需求未響應之前，先disable送出按鈕），這(zhè)又不必要的增加了程序員的負擔。目前已知有自動處理此問題之開(kāi)發(fā)框架似乎隻有ZK。