DWR 的缺点是什么？
在内网中使用DWR时，会出现性能或安全问题等缺点吗？ 直接 Web 远程处理是一种使用 Ajax 请求从 js 文件联系服务器的工具。
While using DWR in a intranet, will disadvantages like perfomance or security issues occur?
Direct web remoting is a tool which uses Ajax request to contact a server from a js file.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我要注意的一件事是，与（正常）全页 HTTP 交付相比，您的服务器很可能会受到更多 HTTP 请求的攻击。
让我解释。 当您的网页支持 AJAX 时，您的客户端最终将创建更多 HTTP 请求（例如）表单填写、页面片段重新生成等。我见过开发人员疯狂使用 AJAX 的场景，并将网页制作为很大程度上是动态的文档。 这会带来良好的用户体验（如果做得好），但每个请求都会导致服务器命中，从而导致可扩展性和延迟问题。
注意 - 这并不是 DWR 所特有的，而是一个 AJAX 问题。 我用过DWR，效果很好。 不幸的是，我发现它工作得非常好，而且非常容易，以至于一切都成为远程处理的候选对象，并且您最终可能会收到大量的小请求。
One thing I would watch out for is that your server will most likely get hit by more HTTP requests than if you have the (normal) full page HTTP delivery.
Let me explain. When your web page is AJAX-enabled, your clients will end up creating more HTTP requests for (say) form filling, page-fragment regeneration etc. I've seen scenarios where developers have gone AJAX-crazy, and made the web page a largely dynamic document. This results in a great user experience (if done well), but every request results in a server hit, leading to scalability and latency issues.
Note - this isn't particular to DWR, but is an AJAX issue. I've used DWR, and it works nicely. Unfortunately, I found that it worked so well, and so easily, that everything becomes a candidate for remoting, and you can end up with huge numbers of small requests.
我使用 DWR 进行了一个项目 - 一个非常好的工具。
但我对发展速度并不确信。 他们确实在开发日志上发布了他们正在努力推出 3.0 的信息，但最后一个稳定版本 - 2.0 - 于 2006 年夏天发布。从支持的角度来看，这有点令人担忧 - 特别是错误修复。
I worked on a project with DWR - a really nice tool.
I'm not convinced about the pace of development though. They did post on the development log that they're working on getting 3.0 out the door, but the last stable release - 2.0 - was out in summer 2006. It's a bit worrying taken from a support perspective - bug fixes especially.
我遇到的主要问题是尝试在系统上编写负载测试脚本，其中大部分工作是通过 DWR 调用完成的。 与仅回复一堆带有更改参数的 URL 相比，调用的格式很难复制。
尽管如此，DWR 仍然是一个优秀的框架，并且可以实现 Javascript -> Java RPC 非常简单。
Main problem I've experienced is trying to script a load test on a system where the main bulk of the work is done via DWR calls. The format of the calls is difficult to replicate when compared with just replying a bunch of urls with changing parameters.
Still DWR is an excellent framework and makes implementing Javascript -> Java RPC pretty damn easy.
当前 DWR 3.x 缺少一个任何用户都应该小心的功能，即当 bean 实例具有 NULL 值属性时，这些属性仍将注入到 JSON 中，并且这些冗余数据确实会影响性能。
当属性值为 NULL 时，通常不应将其发送到前端。
问题详细信息： http://dwr.2114559.n2 .nabble.com/Creating-Custom-bean-converter-td6178318.html
One feature missing of current DWR 3.x that any user should take good care is that when an instance of a bean has properties of NULL value, those properties will be still injected to the JSON and these redundant data DO affect the performance.
When a property has the value of NULL, usually it should not be sent to frontend.
Details of problem: http://dwr.2114559.n2.nabble.com/Creating-Custom-bean-converter-td6178318.html
当您的站点有大量 ajax 调用时，DWR 是一个很棒的工具。
每个进行 dwr rpc 调用的页面都需要包括：
a) 与所进行的调用相对应的接口文件。
和
b) 与 dwr 捆绑在一起的 js 文件，其中包含使这些调用成为可能的 dwr 引擎代码。 例如
优化 Web 应用程序时经常使用的一种技术是在以下情况下尽可能多地使用浏览器缓存：资源（如 js 文件）在服务器上未发生更改。
engine.js 是永远不会改变的东西，除非你将 dwr 升级到更新的版本。 但是，默认情况下，engine.js 不是您的网络服务器提供的静态文件。 它作为 dwr 工具本身的一部分捆绑在一起，并由 dwr 控制器/servlet 提供服务。这对客户端缓存没有帮助。
因此，将engine.js保存在Web服务器的文档根目录下并让Web服务器将其作为静态文件提供是有益的。
DWR is a great tool when your site has a lot of ajax calls.
Each page that makes dwr rpc calls needs to include :
a) an interface file corresponding to the calls being made.
and
b) a js file bundled with dwr that contains the dwr engine code that makes these calls possible. for e.g.
<script src="/dwr/engine.js" ></script>one technique that is frequently used while optimizing web applications is to use the browser cache as much as possible when a resource(like a js file) has not changed on a server.
engine.js is something that will never change unless you upgrade your dwr to a newer version. But, by default, engine.js is not a static file served by your webserver. its bundled as part of the dwr tool itsef and is served by the dwr controller/servlet.this doesnt aid client side caching.
So, it is beneficial to save engine.js under the document root of your webserver and let the webserver serve it as a static file.
与其他传输对象（封送）的解决方案相比，最大的区别是对象引用。
例如，如果你用它来传输一棵树：
A
|-B
|-C
in a list {A,B,C}:
B.parent = A
C.parent= A
那么 A 是 JavaScript 中的同一个对象！
不利的一面是，如果您有具有循环依赖关系的复杂结构和大量对象：A<-B、B<-C、C<-B、C<.A，...它可能会崩溃。
不管怎样，我在一个真实的项目中使用它，数百家公司在生产中使用它，将数千个对象传输到单个 html 页面，以便绘制复杂的图形，并且它运行良好，性能良好。
The biggest difference among other solutions to transfer objects (marshaling) is object references.
For instance, if you use it to transfer a tree:
A
|-B
|-C
in a list {A,B,C}:
B.parent = A
C.parent= A
then A is the same object in Javascrit!
On the bad side, if you have complex structures with circular dependencies and lot of objects: A<-B, B<-C, C<-B, C<.A,... it could crash.
Anyway, I use it in a real project used by many hundreds of companies in production to transfer thousands of objects to a single html page in order to draw a complex graph and it works nicely with a good performance.