1. I take it, then, that DWR 2, alone, is not a full MVC framework. Is that correct? 2. Do the example application in your book use DWR 2 alone, or do they use any other frameworks to fill in some of the details? 3. If you use DWR with other web application frameworks, would you care to briefly explain which ones you prefer and why?
Ok, while I have a few minutes during the day I'm going to try and answer a few of these questions sooner than later, starting with this one because I like it a lot myself
It's correct Michael that DWR is not itself a full MVC framework... I'd say it really only represents the controller portion of such an architecture.
The examples in my book use DWR alone, I don't examples of integration with Struts for example, largely because I just don't see that integration as being very valuable. What DWR offers in this regard doesn't seem terribly useful to me, but it's more than that, and that goes into an answer for your third point.
I have a very strong opinion that has formed over the last year or so of experience with DWR that DWR *by itself* is all the framework anyone needs. More to the point, it leads to much cleaner and simpler code, and a lot less of it.
We built a highly complex app at work on top of Struts. We then began rolling some DWR into the mix. What we found is that the parts built with DWR was just plain better in terms of what we had to write, how much we had to write, and how easy it was for junior developers to grasp it. The Struts parts hy contrast, largely using Dojo's AJAX functionality on the client, was just plain too much work. Now admittedly that's Struts 1, but I've done some proof-of-concept wotk with Struts 2 as well and it's almost worse in many regards.
DWR, as I say in my book, is a paradigm shift, if you let it be. What I mean is that it leads you down a path of doing everything with POJOs and really decoupling the client form the server as a consequence (maybe an indirect consequence, but a consequence none the less). You wind up with something a lot closer to a true SOA, although obviously it's not, it's RPC-based, but you start to say "ok, let me create my simple API, and then the client is just calling it". It really completely gets you away from that page-request-new page paradigm that most MVC frameworks push you down.
In fact, I've had conversations with some people about actually starting up a new project that takes DWR and literally builds a whole framework around it to compete with Struts and all the others out there. If it wasn't for a lack of time thus far I would have had this off the ground already! But that's where I think things should be going frankly, *not* tighter integration with these other frameworks because instead of simply filling the whole as you suggest, DWR in fact makes all the rest quite superfluous IMO, and in many ways it's actually counter-productive to try and make such integration work.
So when you write that you eliminate the rest of the MVC, doesn't that muddle your code? Or do you mean that you eliminated a framework, but you still keep the stuff doing presentation work separate from the pieces that handle business logic and persistence?
I got into Java web development at a company with a Struts 1 application. It worked, and the coding and architecture that the original creators built around Struts was very nicely done. (At least, as far as someone new to the field like me could tell.)
I'm comfortable enough with Struts 1 that I can land a new job with it. But I would prefer not to use it. I'm been hunting for a related skill set that can balance getting a good job with working on efficient and intuitive skill sets. Maybe this is it. I've looked at Struts 2, and it looks like a dozen improvements to Struts 1 but enough of a learning curve between them that much of the advantages are negated. (I mean no disrespect to anyone working on the project. I'm sure after a few months I would be much more productive with Struts 2 than Struts 1. But it's not the Amazing Revolutionary Improvement I was hoping to find.)
Thanks for the thought provoking response! I am a Struts 1.x developer. I have looked at some other MVC frameworks and my thoughts seem to match up with some of Michael's. Other MVC frameworks seem to be better than Struts but nothing revolutionary. They all seem to be built around the "fill out a form, submit the page, refresh the page" mentality. The same type of thing for non-Java frameworks...they just let me create the same crappy web pages faster. GWT is about the only thing that looks really exciting (I need to spend some more time with GWT).
Just make a few clarifications, especially for those less versed in web applications:
Originally posted by Brent Sterling: I was developing much better user interfaces in VB and C++ 10 years ago
Any web toolkit or framework isn't going to allow you the full range of UI available to desktop applications. They still run in the browser and are still bound by the limitations of DHTML and HTTP.
back to creating easy to use, rich interfaces that are not chained down by the limitation of browsers and html.
I might just have to look a little closer at DWR to see how I can move beyond the request/response cycle.
DWR is still bound by the HTTP request cycle; it just cleverly uses Ajax to help your code pretend that you're not.
Not trying to dash anyone's dreams here, but just wanted to make sure that no one gets the impression that these tools turn the browsers into something that they are not. [ March 11, 2008: Message edited by: Bear Bibeault ]
For me, what I'm finding is that you can still maintain the separation you're looking for from a "classic" MVC framework, but things kind of shift around a bit
What winds up happening is that your view and control layer migrate down to the client, while your model of course stays on the server.
It's also worth noting that MVC was a pattern devised back in the heavy Swing days, it wasn't originally a web framework paradigm. Some even argue that Struts, and most other "MVC" frameworks, in fact are nothing of the sort. I'd rather not get into a complex CompSci debate on that point though
DWR blurs the lines between what runs on the server and what runs on the client. If you forget for just a moment, as it's easy to do with DWR, that your code is running in two different places, you start to ask yourself "what does MVC actually MEAN in this context"? It's the same as asking what MVC means in a Swing application, when all the code truly *IS* running in the same place. You can still do MVC, but all the layers are essentially in the same place. By extension, having the view and control code out on the client while the model stays on the server doesn't hurt my head
I did not think that you did. My response was to Brent's post, which when read by someone who has yet to wrap their brains around how web apps work, might be construed incorrectly.
Joined: Feb 08, 2006
Not to get too far off topic but maybe it is about time to change how we think about "how web app work". Whether having desktop-like web application (like Gmail) running in a browser is a good thing or not is debatable, but there sure seems to be a movement towards that type of application. I understand the basics of DWR and I know that it is not a magic bullet (and it is not a user interface widget library).
does DWR 2 provides support to integrate with the latest version of Spring and Sun's JSF? are there examples in the books that show integration with various popular open source framework and even commerce products ?
BEA 8.1 Certified Administrator, IBM Certified Solution Developer For XML 1.1 and Related Technologies, SCJP, SCWCD, SCBCD, SCDJWS, SCJD, SCEA,
Oracle Certified Master Java EE 5 Enterprise Architect
Joined: Dec 16, 2004
I'm not sure if DWR integrates with the LATEST versions of Spring and JSF, but it does offer integration with both.
I also don't think there's very much value in this integration. Having Spring create your remotable classes is fairly nice, but aside from that, the integration didn't, and still doesn't strike me as very useful. As such, I talk about it in the book fairly briefly and don't actually show it in use.
Then again, they couldn't have paid me enough to write positively about JSF, but that wasn't your question I suppose
I started reading about DWR few days back. Its strikingly different from the usual web-app technologies I have worked on till date (read as huge amount of Struts). One question that invariably comes to mind is can DWR really replace MVC ?
One may argue about the usability of MVC but the more mature frameworks like Struts and JSF give lots of tools in the MVC. Validation, interpretors(struts2) etc..
From whatever I have understood about DWR from my little reading and if I can put it down in few words is that its nothing but say 'RPC over HTTP'. so, Can we really replace a MVC architecture with DWR ?