This forum is now a read-only archive. All commenting, posting, registration services have been turned off. Those needing community support and/or wanting to ask questions should refer to the Tag/Forum map, and to http://spring.io/questions for a curated list of stackoverflow tags that Pivotal engineers, and the community, monitor.
No announcement yet.
Difference between Spring MVC Web Framework and Web FlowPage Title Module
MVC is an implementation of the Model View Controller design pattern, webflow is an implementation of a "web flow" state machine.
Web flow sits on top of springs MVC and allows you to define complex navigational flows.
Quite simply; if you have lots of independant single pages, which don't do much and don't interact, use plain old MVC. If you have a set of pages that represent a workflow, use webflow to model the workflow. If you have both; mix and match
Here's a repost of some decent stuff I said to answer the question: "what's the benefit of delegating to webflow from Struts / Spring MVC instead of just using their own controllers?"
The main benefit is navigation decisions can be made dynamic: they’re not baked in. Furthermore, you don't have to jump through hoops to make complex navigation decisions--the framework is designed to support the non-trivial cases. Reusability and modularility are also wins: flows can embed other flows, which can embed other flows, etc.
Flows are self-contained in the sense they have a well-defined contract for use -- you can start them and pass them input, you can tell them "something" happened and they’ll respond to it, and when they end they can produce output for you, but you cannot effect (or even know about) their internals: they're black boxes. They have a lifecycle.
In SWF, Views (clients) signal events. A web flow responds to those events to decide what to do next. The criteria for how it responds is fully configurable by you in a declarative fashion.
You simply don't get that same capability Struts -- from your views, you bake in requests that hit a particular URL. Actions are routed those requests and they do some stuff and immediately select the next view. In webflow you just say something happened -- e.g "submit" and the flow determines what happens next, and what happens might be a complex series of processing (a dynamic chain of stuff) before returning control to the client. The flow itself is the controller--a powerful one based on a finite state machine... what it decides to do "next" on the occurence of any event does not have to be deterministic: it can be dynamic!
The whole lifecycle management aspect is not handed by Struts because Struts has no first-class "flow" concept. There is simply no concept there of something that is "longer than a request but shorter than a session." A lot of business processes that involve input from the user are like that: like paying your taxes on-line, for example. Web flow makes the "flow" -- defined as an application transaction that "pauses" periodically to get input from the user-- a first class thing with a well-defined lifecycle. As such, you can listen to and respond to that lifecycle, and you get automatic state management.
I could go on... The main point: webflow is a powerful controller. That's it. Use it when you need its power, use plain old controllers where you don't. You mix and match as needed in one app.
I'm considering using Spring+Hibernate for an end-to-end web app (~20 screens, ~10 tables).
Also, other folks in my group are eyeing the solution I pick closely, so they can use it as a model for future/new projects. Given my app is straightfoward/small, it is less risk to try a new technology combo versus Struts+Hibernate (used currently).
You will find a comprehensive comparison of Spring MVC, Struts 1.1 and WebWork2 in Rod Johnson's book "J2EE Development without EJB". It should give you the overview you need.
My experience with Spring MVC is that is provides more hooks in the Controllers in terms of Pre- and Postprocessing and a more flexible inheritance hierachy. Also, you are not required to extend any framework classes in your form backing objects - this will let you reuse your Business Objects in that role.