Spring controllers programming style

Question

I come from some experience with MVC frameworks and recently I started to get interested in Spring. I think it's a good framework, for what I've seen until now. Anyway, in my past experiences I was used to a different programming style, especially for the structure of controllers. The way I was used to to employ controllers was different. Of course I used to map somehow a request to them (think of structs with various actions), but then what I really liked was that you could pass actions to other controllers, then they would remain the "active" controller and those would be responsible of handling the next request, may it come from an HTTP request or from something else. I did enjoy this because it was very good to keep the state of a user session in an automated way, making code clean and separating different situations in different controllers. Now I've read Spring Web MVC and the docs only talk about controllers that answer requests, but they don't keep state and there's no word about chaining controllers (apart from forwarding) and state retention.

How do you handle these topics in spring, is there a different way, or should I implement my own stateful controllers and state/action classes?

I hope my question is clear enough and I apologize for its broadness.

Answer 1

In Java, the difference between stateful / stateless web frameworks is usually described as the difference between action-based and component-based frameworks.

Both approaches are valid, but usually when you choose a Framework you are stuck with that framework's way of doing it:

Popular Action Frameworks:

• Struts (and Struts 2)
• Stripes
• Spring MVC (You can add Conversational state through Spring WebFlow)

Popular Component Frameworks:

• Wicket
• JSF
• Seam
• Tapestry

(There are of course many more, in both categories)

Answer 2

In Spring MVC you could use the stateless controllers forwarding the request / invoking session scoped beans.

But if this is a good idea or not strongly depends on your use case. -- I would do this only if I there are only a few of this "strange" controllers. -- If you have a lot of them I think it is worth to look for an other solution. (for example JSF with Spring)