What is the disadvantage of DWR?

问题:

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.

回答1:

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.

回答2:

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.

回答3:

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.

回答4:

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

回答5:

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.

回答6:

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.