JSON-RPC-Java 和DWR比較（轉）

當前在以Java為後臺的AJAX框架中，比較有名兩個是JSON-RPC-Java 和DWR。

Swato與他們的共同之處是實現了JavaScript與Java 物件間的資料轉換與遠端方法呼叫。從各自提供的unitTest Demo可以看到這一實現的支援能力基本是相同的。

各自的差異主要在以下幾個方面。

1.為開發人員開發前臺JavaScript提供的支援。

由於採用AJAX框架後，很多View和Control的程式碼需要轉移到前臺用JavaScript實現。然而JavaScript的程式設計畢竟是比較痛苦的。 在JSON-RPC-Java中，從伺服器返回到前臺的雖然是JSON--JavaScript物件，但是他沒有提供元件幫助開發人員處理這些物件。 對於返回XML的框架，一句一句書寫DOM層次訪問是比較痛苦的。

而對於HTML DOM的操作，也是比較痛苦的，所以所以DWR提供了一系列DWRUtils來幫你減輕這一部分工作。但是對於一些需要更加靈活的View處理，利用DWRUtils仍然感覺不夠用。

在Swato中，客戶端接受的資料可以是JSON(Swato的後臺是直接把Java物件對映成JSON)，也可以是XML(你可以從遠端URL中獲取XML, 它在Swato客戶端引擎中被轉化為JSON，參見RSS Reader的例子)。所以對於開發人員來說，它在客戶端所要關心的只是JavaScript物件。(結構與Java物件或XML結構對應)。然後利用Swato提供的一些View元件(AutoSuggest, Select, Form)進行渲染。對於自定義性比較強的View控制元件，你可以在前端使用Template引擎 （來自TrimPath,類似於Velocity的簡單語法）。甚至可以把它封裝成你自己的元件，只要在其中實現gotResult與gotError函式，便可以很輕鬆的與Swato遠端呼叫功能整合。參見(CRUD例子中的程式碼。)

Swato力圖在客戶端為開發人員減輕JavaScript程式碼的編碼量，其實Swato的unitTest例子來自於DWR。 類似的測試功能，在邏輯控制上，DWR用了幾百行的JavaScript而在Swato上只需要幾十行。

不管用哪一個框架，由於JavaScript缺乏強大的編輯器和偵錯程式，所以開發起來還是比較麻煩，對此，Swato在前臺整合了fvlogger, 相當於Java方面的Log4j，為Js的開發帶來更大便利。

2.後臺服務的註冊與訪問控制方式。

在後臺服務的註冊方式上，JSON-RPC-Java預設的是在Session中的Bridge裡註冊要使用的Java物件。這種方式有很多的限制，比如使用的時候需要JSP或者Servlet程式中來進行註冊。形式不夠靈活，服務的週期管理也比較麻煩。這是JSON-RPC-Java被批評的重點。

DWR有了很大的進步，它用dwr.將你需要暴露的服務明確地定義在其中，在前臺的JavaScript中，用