DWR的缺点是什么？

在Intranet中使用DWR时，会出现性能或安全问题等缺点吗？直接Web远程处理是一种使用Ajax请求从js文件联系服务器的工具。

我要注意的一件事是，与具有（正常）全页HTTP传送的服务相比，您的服务器很可能会受到更多HTTP请求的影响。

让我解释。当您的网页启用了AJAX时，您的客户端最终会创建更多的HTTP请求（例如）表单填充，页面片段重新生成等。我已经看到开发人员已经疯狂地使用AJAX的情况，并使网页变为很有活力的文件。这可以带来出色的用户体验（如果做得好），但每次请求都会导致服务器命中，从而导致可伸缩性和延迟问题。

注意 – 这不是DWR特有的，而是一个AJAX问题。我使用过DWR，效果很好。不幸的是，我发现它运行得非常好，而且很容易，所有东西都成为远程处理的候选者，并且你最终可能会收到大量的小请求。

我使用DWR开展了一个项目 – 一个非常好的工具。

但我并不相信发展的步伐。他们确实在开发日志上发布了他们正在努力将3.0推出的问题，但最后一次稳定版本 – 2.0 – 已于2006年夏季推出。从支持角度来看，这有点令人担忧 – 尤其是错误修复。

我遇到的主要问题是尝试在通过DWR调用完成大部分工作的系统上编写负载测试脚本。与仅使用更改参数回复一堆url相比，调用的格式很难复制。

仍然DWR是一个优秀的框架，并使实现Javascript – > Java RPC非常容易。

任何用户都应该注意的当前DWR 3.x缺少的一个特性是当bean的实例具有NULL值属性时，这些属性仍将被注入JSON，这些冗余数据会影响性能。

当属性的值为NULL时，通常不应将其发送到前端。

问题详情： http ： //dwr.2114559.n2.nabble.com/Creating-Custom-bean-converter-td6178318.html

当您的网站有很多ajax调用时，DWR是一个很棒的工具。

进行dwr rpc调用的每个页面都需要包括：

a）与正在进行的调用相对应的接口文件。和b）与dwr捆绑在一起的js文件，其中包含使这些调用成为可能的dwr引擎代码。例如

在优化Web应用程序时经常使用的一种技术是在服务器上没有更改资源（如js文件）时尽可能多地使用浏览器缓存。

除非将dwr升级到更新版本，否则engine.js永远不会改变。但是，默认情况下，engine.js不是您的网络服务器提供的静态文件。它捆绑为dwr工具itsef的一部分，由dwr控制器/ servlet提供服务。这不会帮助客户端缓存。

因此，将engine.js保存在Web服务器的文档根目录下并让Web服务器将其作为静态文件提供是有益的。

传输对象（编组）的其他解决方案中最大的区别是对象引用。

例如，如果您使用它来传输树：

一个

| -B

| -C

在列表{A，B，C}中：

B.parent = A C.parent = A.

那么A就是Javascrit中的同一个对象！

另一方面，如果你有复杂的结构，循环依赖和很多对象：A <-B，B <-C，C <-B，C <.A，......它可能会崩溃。

无论如何，我在生产中的数百家公司使用的真实项目中使用它来将数千个对象传输到单个html页面以绘制复杂的图形，并且它具有良好的性能。