Spring MVC independent from Web Layer

[milosh]

I am currently working on application, which requires presence of web, desktop, palm and as many as possible kinds of clients. Main advanture in this and similar applications is to make as reusable code as possible. Using Spring as underlying IoC container is not an issue in all clients. Business objects, model and intergration part can be also shared with different setups. Problem, which I identifed in Spring MVC are controllers. Complete controller part of framework relies on HttpServletRequest and HttpServletResponse. If we set aside cookies, http headers and similar things, which are part of HttpServletRequest/Response, HttpSession, ServletContext we can get interface common for all of them. Name it Storage, Cache, whatever. It boils down to set, get, remove and inner dependencies (Request -> Session, Session -> Context).

One approach is to use interface like Controller and implement everything from scratch (CommandController, FormController, Wizard and so on). Problem is that even Controller is fully dependent on Web concepts.

Alternative approach, which I took was to implement Strategies in already existing controllers. SimpleFormController would have SimpleFormControllerStrategy, which will do the same thing, but with no dependencies to Web concepts. In order for this to work, I implemented simple interface called Storage, which contains get, set and remove Object (default implementation goes to HashMap). Request, Session and Context are extended interfaces from Storage and implement inner dependencies. Wrapper for SimpleFormController will take request and wrap it into HttpRequestAdapter, which implements Request interface. Controller Strategies will be called with that request adapter, which contains session adapter and servlet context adapter. This approach will render my controllers independent from web layer, hence reusable in desktop client.

Complete hassle arround the wrappers is to keep functionallity arround creation of commands from request parameters. Everything would be rather simple if only dispatcher servlet would "know" for HttpServletRequest and from that point different kind of adapters to kick in.

Idea came from the fact that desktop clients also have MVC pattern as web clients.

I am still in the phase of getting acquainted with AOP approach. Maybe AOP can offer even simpler solution instead of controller wrappers.

Thoughts?

[Alef Arendsen]

It is in fact possible to create a different controller handling mechanism. This feature isn't fully documented, but you should be able to figure it out using some pointers I guess:

Spring uses a HandlerAdapter to deal with objects returned from the HandlerMapping. There are currently two HandlerAdapter implementations, the SimpleHandlerAdapter (dealing with the org.springframework.web.servlet.mvc.* controller infrastructure) and the ThrowAwayControllerHandlerAdapter (dealing with the org.springframework.web.servlet.mvc.throwaway controllers). The latter resembles webwork more in terms of being more command-oriented.

To get to a controller infrastructure that's independent of the HttpServletRequest you'd have to create a new HandlerAdapter and add it to the XXX-servlet.xml. In the HandlerAdapter you could transform the HttpServletRequest into something transport-agnostics and call the delegate the request to the controller.

Drawback is (and this is only because Spring initially chose not to be HttpServletRequest-independent) that you'll have to re-create the controller infrastructure to remove the dependency on the servlet api (unless you're going to do the whole strategy thing you were talking about).

Hope this helps a bit (you might wanna have a look at the JavaDOC for the HandlerAdapter).

regards,
Alef

[milosh]

Thanks a lot for the quick reply.

I actually already implemented strategy I described. It looked to me as the most convenient way to reuse already existing request/response handling structure and still achieve independence for my controllers. I do not see too much point in recreating complete controller network from the scratch and in that I see the decision of Spring team in the first place. I was wondering if you can give me some useful tip on implementing the strategy.
It could be that Spring envisiged some sophisticated way of handling this kind of requests. As I mentioned I am reading about AOP. Would you think that that could be the way to go also?

Thanks,

[milosh]

I was wondering if it possible to split method invokeNamedMethod in MultiActionController in two protected methods. One would identify a method, which needs to be invoked. Second would make the actual call to method. In that way, the strategy approach could override call to the method and make the call with changed parameters.

Is there a way that I can adapt method parameters using AOP? I have interface A, with method "handle(param1, param2)". I want to proxy AImpl with interface B, which has method "handle(param3, param4)". I would like to maybe use before advice and modify parameters sent to interface B and adapt them for the interface A.

Is that feasible with Spring AOP?

Thanks,

[pulse1014]

This subject has been brought up before...

http://forum.springframework.org/viewtopic.php?t=1370

Unfortunately, it seems there are no plans to either rename Spring MVC to Spring Web MVC or to actually create a true generic MVC framework and not make the same mistake as Struts...

If you want a good MVC framework to use check out Xwork (it has web counterpart called Webwork). [/url]

[katentim]

Unfortunately, it seems there are no plans to either rename Spring MVC to Spring Web MVC

Actually, this post shows it has always been called "Spring Web MVC" (see the reference docs.) - and the classes are under org.springframework.web.servlet.mvc package.