When handler code isn't trivial, then this code should be considered to be moved to a separate service class. This makes the business code both better to test and reusable.
This is a simple example:
@RequestMapping(value="/service/{id}/{command}") public ModelAndView handle( @PathVariable("id") Integer id, @PathVariable("command") String command) { Object result = getService() .performComplexComputation(id, command); return HandlerHelper.createModel(result); }
It's possible to use Spring's mechanism for an annotation based automatic instantiation and autowiring of handlers and other beans. This requires the bean classes to be annotated with
@Controller,@Service,@Injectetc. as well as using a<context:component-scan>declaration.In contrast to this approach, CoreMedia suggests using the XML based way for defining and wiring beans. The reason is that in larger projects, using autowired beans may prove difficult to handle, especially when using external extensions.
When declaring beans in XML, a developer exerts much more direct control over the application context.
Several handler methods may exist in the same class for the same URI path if they handle different request methods (such as GET or POST)
- The best practice for handling POST requests can be found here Section 4.3.6.4, “Handling POST requests”
- The best practice for handling redirects can be found here Section 4.3.6.5, “Handling redirects”
 |  |  |
 |