No, really, what is it? Are you one of those people who ever wondered why there is actually more than one? Or you work with Struts for 5 years in a row, and think it is the best, just because you know all the nasty hooks you have to implement to make it do what you actually need?
Are you one of those die hard Rails fans, who (as most of Rails developers) does not really know Java, but already has a lot to say how bad it is?
Do you work in C++, and feel absolutely confident, that the framework, your company had developed for the last 25 years, that build web pages via socket programming is the best, and the most efficient one out there?
Is your company big enough, so it has a mature team of software (what they call themselves) architects, that take open source frameworks, and write their own single wrapper framework around it that, as they think (since they wrote it), is the 8th wonder of the (ancient) world?
You, see, I am a consultant – I know many of you, since I met “you” before :)
This one will be a very short article about my experiences with several Java Web Frameworks out there. Here we go:
| Spring MVC |
Would be a good choice for the most of your needs
(I’ll give a short controller example below) |
| Wicket |
Interesting to look at – no XML, no JSP (JSTL), just Java and HTML. Can mimic a flow in a WebPage object. Better separation of concerns than, for example, in GWT (e.g. no Javish CSS, etc.). Good Community
The only thing that is off is your dynamic HTML elements are done in Java |
| Spring Webflow | Yes – it is a separate beast. It mostly is good, and makes sense, however, in practice, once you need to do something a bit more complex that a shopping cart or a hotel booking app (hint, hint), you can run into problems. “Back button” and “Double click” are not very well handled by the framework, may get an exception while bookmarking (there is a magic recipe, but far from being simple, and intuitive), sharing data across the flow, last resort error handling are not simple, etc. |
| Stripes | Good / simple (no XML – conventions), but not very actively maintained – hence not as mature. (good community though) Worth to look at for simple projects. |
| Struts | Just architected wrong from the very beginning: Validation (XML – why? What about minimum search criteria, what about several, what about nested OO validators!?) / 0 for NULLs / Multi Action Forms / Testing (without StrutsTestcase) / etc. ) Improved a bit since WebWork merging, but still lots of “code smells”. |
| JSF | Quite hard to keep up with all these JSF based JSP tags + integration with security is not simple + full JSF solutions are usually Frankensteins with many pieces from different vendors. |
| Tapestry | Not bad, actually make sense, when you get it. But have you ever looked and tried to follow the Tapestry code? – Very complex implementation, if ever need to look inside the code + Tapestry does take time to learn, so forget about a new off-shore team, or fresh out of college not so geeky grads, taking it on. |
And here is why I like Spring MVC:
- Binding / Validation is done just right – clean, testable, reusable
- Multiple View options ( PDF, XML, Excel, Atom, etc… ) done easy [AbstractExcelView, AbstractFeedView, AbstractJExcelView, AbstractPdfView, AbstractUrlBasedView, AbstractXsltView ]
- Annotation based – no XML madness, and very clear when looking at the code – check the Pet Clinic in Spring 3.0 M3
- Integrates with Spring JS very nicely ( in case needed )
- Handing requests and parameters with ( Spring ) expression language – quite flexible
- In Spring 3, MVC is actually REST aware (GET, POST, PUT, DELETE)
You can download Spring STS, import sample projects, and see many examples on how to use it, but here is a very simple controller example from Spring’s Pet Clinic:
@Controller // it’s a controller public class ClinicController { @RequestMapping("/welcome.do") // that all there is to mapping public void welcomeHandler() { } /** @return a ModelMap with the model attributes for the view uses org.springframework.core.Conventions */ @RequestMapping("/vets.do") public ModelMap vetsHandler() { return new ModelMap(this.clinic.getVets()); } @RequestMapping("/owner.do") public ModelMap ownerHandler(@RequestParam("ownerId") int ownerId) { // parameters are passed in easily return new ModelMap(this.clinic.loadOwner(ownerId)); } } |
It all depends on project’s requirements / timeline / resources / requirements / technologies already in place / etc… But having a choice, I do choose Spring MVC – it just makes sense: easy implementaion with Spring Roo / integration with Spring’s back end / support / community / releases / etc… I also like where Wicket is going, but it feels like “it is still going…”
In any case – good luck, and remember – if it does not have to be Java, but you still like to “stay close”, I would definitely give Grails a shot.