DWR的缺點是什麼？

Question

在Intranet中使用DWR時，會出現性能問題或安全問題嗎？ 直接Web遠程處理是一個使用Ajax請求從js文件聯繫服務器的工具。

Answer 1

我會注意的一件事是，如果你有（普通）完整頁面HTTP傳遞，你的服務器很可能會被更多的HTTP請求命中。

讓我解釋一下。當你的網頁啓用了AJAX時，你的客戶端最終會創建更多的HTTP請求（比如說）表單填充，頁面片段重新生成等等。我已經看到了開發人員瘋狂使用AJAX，並使網頁成爲基本上是動態文件這會產生良好的用戶體驗（如果完成的話），但是每個請求都會導致服務器命中，從而導致可伸縮性和延遲問題。

注意 - 這不是DWR的特殊情況，而是AJAX問題。我使用過DWR，並且它工作得很好。不幸的是，我發現它工作得很好，而且很容易，所有東西都成爲遠程處理的候選對象，並且最終可能會產生大量的小請求數。

Answer 2

我用DWR工作過一個項目 - 一個非常好的工具。

雖然我不相信發展的步伐。他們確實發佈了on the development log，他們正在努力讓3.0版本走出去，但最後一個穩定版本--2.0版在2006年夏季發佈。從支持角度來看，這有點令人擔憂 - 特別是bug修復。

Answer 3

我遇到的主要問題是試圖在系統中通過DWR調用完成大部分工作的腳本負載測試。與僅僅通過改變參數回覆一堆網址相比，呼叫的格式很難複製。

仍然DWR是一個很好的框架，使得實現Javascript - > Java RPC非常容易。

Answer 4

當你的網站有很多ajax調用時，DWR是一個很棒的工具。

，使得DWR RPC調用每個頁面都需要包括：

一）對應調用的接口文件正在取得進展。 和 b）與dwr捆綁的js文件，其中包含使這些調用成爲可能的dwr引擎代碼。例如， <script src="/dwr/engine.js" ></script>

優化Web應用程序時經常使用的一種技術是在資源（如js文件）在服務器上未更改時儘可能使用瀏覽器緩存。

engine.js是永遠不會改變的東西，除非你升級你的dwr到更新的版本。但是，默認情況下，engine.js不是您的Web服務器提供的靜態文件。它作爲dwr工具itsef的一部分捆綁在一起，並由dwr控制器/ servlet服務。這不會幫助客戶端緩存。

因此，將engine.js保存在Web服務器的文檔根目錄下並讓Web服務器將其作爲靜態文件保存是有益的。

Answer 5

當前DWR 3.x缺少一個功能，任何用戶都應該小心，當一個bean的實例具有NULL值屬性時，這些屬性仍將注入到JSON中，並且這些冗餘數據會影響性能。

當屬性的值爲NULL時，通常不應將其發送到前端。問題

詳情：http://dwr.2114559.n2.nabble.com/Creating-Custom-bean-converter-td6178318.html

Answer 6

其他解決方案之間最大的區別傳輸對象（編組）爲對象的引用。

舉例來說，如果你用它來傳輸樹：

一個

| -B

| -C

在列表{A，B，C}：

B.parent = A C.parent = A

則A是第Javascrit中的同一個對象！

在不好的一面，如果你有循環依賴和很多對象的複雜結構：一個< -B，B < -C，C < -B，C < .A，...它可能會崩潰。

無論如何，我將它用在一個真正的項目中，由成百上千的生產公司使用，將數千個對象轉移到單個html頁面上，以繪製複雜的圖形，並且它具有良好的性能。