Model reference
Reference Figure: The MVC Controller Layer
How a request reaches a generated controller, how the controller talks to the service layer and how a view is selected.
The controller layer is deliberately thin. It accepts a request, reads the parameters, calls one service operation and chooses a view. Anything more complex belongs in the service layer, where it can be tested without a web container.
Request path
- The browser sends a request to a mapped path.
- The dispatcher finds the controller method for that path and method.
- The controller calls the service and places the result in the model.
- The view resolver turns the returned view name into a JSP page.
What the recipe generates
- A controller class with one method per action.
- Request mappings for list, show, create, edit and remove actions.
- A form backing object for create and edit screens.
- Binding result handling so that validation errors return to the form.
Keep it thin. If a controller method grows past a screen of code, move the logic into a service method. The controller should read like a table of contents for the use case.
The figure also shows the direction of dependency. Controllers depend on services, services depend on repositories, and repositories depend on the data store. No arrow points the other way. That single rule keeps the application easy to change.