基于A(yíng)jax的應用程序架構匯總及開(kāi)發(fā)面臨的問(wèn)題介紹

　　4.1 WebORB for Java(自從2005年8月)

　是一個(gè)平臺，支持開(kāi)發(fā)AJAX和基于Flash的胖客戶(hù)端應用程序，并可以把它們與Java對象和XML Web服務(wù)相系起來(lái)。在線(xiàn)舉例(http：//www.themidnightcoders.com/examples)

　　4.2 Echo 2(自從3月2005年)

　允許你用純Java代碼編寫(xiě)Ajax應用軟件

　　4.3 Direct Web Remoting (DWR)(2005年)

是一個(gè)框架，用于直接從Javascript代碼中調用Java方法。

　　4.4 SWATO(2005年)

是一套可重用的和良好集成的Java/JavaScript庫，它實(shí)現了一種更容易的方式來(lái)改變你的web應用程序的交互，它是通過(guò)AJAX方式實(shí)現。

　　5 服務(wù)器端：Lisp

　　5.1 CL-Ajax

　實(shí)現Javascript直接調用服務(wù)器端Lisp函數。

　　6 服務(wù)器端：.NET

　　6.1 WebORB for.NET(自從8月2005年)

　是一個(gè)平臺，用于開(kāi)發(fā)AJAX和基于Flash的胖客戶(hù)端應用程序，并能把它們連接到.NET對象和XML Web服務(wù)

　　6.2 Ajax.NET(自從3月2005年)

　是一個(gè)庫，實(shí)現從Javascript到服務(wù)器端.NET的存取。

　　7 服務(wù)器端：PHP

　　7.1 AjaxAC(自從2005年4月)

用單個(gè)的PHP類(lèi)封裝了完整的應用程序。

　　7.2 JPSpan

　　直接把Javascript調用傳遞到PHP函數。

　　7.3 XAJAX

直接把Javascript調用傳遞到PHP函數。

　　8 服務(wù)器端：Ruby

是一個(gè)通常的強力支持Ajax的web框架：

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

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

　　Ajax在本質(zhì)上是一個(gè)瀏覽器端的技術(shù)，首先面臨無(wú)可避免的第一個(gè)問(wèn)題即是瀏覽器的兼容性問(wèn)題。各家瀏覽器對于JavaScript/DOM/CSS的支持總有部分不太相同或是有Bug，甚至同一瀏覽器的各個(gè)版本間對于JavaScript/DOM/CSS的支持也有可能部分不一樣。這導致程序員在寫(xiě)Ajax應用時(shí)花大部分的時(shí)間在調試瀏覽器的兼容性而非在應用程序本身。因此，目前大部分的Ajax鏈接庫或開(kāi)發(fā)框架大多以js鏈接庫的形式存在，以定義更高階的JavaScript API 、JavaScript對象(模板)、或者JavaScript Widgets來(lái)解決此問(wèn)題。如prototype.js。

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

　　將業(yè)務(wù)邏輯及表現層放在瀏覽器，數據層放在服務(wù)器：因為所有的程序以JavaScript執行在客戶(hù)端，只有需要數據時(shí)才向服務(wù)器要求服務(wù)，此法又稱(chēng)為胖客戶(hù)端(fat client)架構。服務(wù)器在此架構下通常僅用于提供及儲存數據。此法的好處在于程序員可以充分利用JavaScript搭配業(yè)務(wù)邏輯來(lái)做出特殊的用戶(hù)接口，以符合終端用戶(hù)的要求。但是問(wèn)題也不少，主因在第一，JavaScript語(yǔ)言本身之能力可能不足以處理復雜的業(yè)務(wù)邏輯。第二，JavaScript的執行效能一向不好。第三，JavaScript訪(fǎng)問(wèn)服務(wù)器數據，仍需適當的服務(wù)器端程序之配合。第四，瀏覽器兼容性的問(wèn)題又出現。有些Ajax開(kāi)發(fā)框架如DWR企圖以自動(dòng)生成JavaScript之方式來(lái)避免兼容的問(wèn)題，并開(kāi)立通道使得JavaScript可以直接調用服務(wù)器端的Java程序來(lái)簡(jiǎn)化數據的訪(fǎng)問(wèn)。但是前述第一及第二兩個(gè)問(wèn)題仍然存在，程序員必須費相當的力氣才能達到應用程序之規格要求，或可能根本無(wú)法達到要求。

　　將表現層[2]、業(yè)務(wù)邏輯、及數據層放在服務(wù)器，瀏覽器僅有用戶(hù)接口引擎(User Interface engine);此法又稱(chēng)為瘦客戶(hù)端(thin client)架構，或中心服務(wù)器(server-centric)架構。瀏覽器的用戶(hù)接口引擎僅用于反映服務(wù)器的表現層以及傳達用戶(hù)的輸入回到服務(wù)器的表現層。由瀏覽器所觸發(fā)之事件亦送回服務(wù)器處理，根據業(yè)務(wù)邏輯來(lái)更新表現層，然后反映回瀏覽器。因為所有應用程序完全在服務(wù)器執行，數據及表現層皆可直接訪(fǎng)問(wèn)，程序員只需使用服務(wù)器端相對較成熟之程序語(yǔ)言(如Java語(yǔ)言)即可，不需再學(xué)習JavaScript/DOM/CSS，在開(kāi)發(fā)應用程序時(shí)相對容易。缺點(diǎn)在于用戶(hù)接口引擎以及表現層通常以標準組件的形式存在，如需要特殊組件(用戶(hù)接口)時(shí)，往往須待原框架之開(kāi)發(fā)者提供，緩不濟急。如開(kāi)源碼Ajax開(kāi)發(fā)框架ZK目前支持XUL及XHTML組件，尚無(wú)XAML之支持。

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