The Model layer
The Model layer represents the part of your application that implements the business logic. It is responsible for retrieving data and converting it into meaningful concepts for your application. This includes processing, validating, associating or other tasks related to handling data.
At a first glance, Model objects can be looked at as the first layer of interaction with any database you might be using for your application. But in general they stand for the major concepts around which you implement your application.
In the case of a social network, the Model layer would take care of tasks such as saving the user data, saving friends’ associations, storing and retrieving user photos, finding suggestions for new friends, etc. The model objects can be thought as “Friend”, “User”, “Comment”, or “Photo”.
The View layer
The View renders a presentation of modeled data. Being separated from the Model objects, it is responsible for using the information it has available to produce any presentational interface your application might need.
For example, as the Model layer returns a set of data, the view would use it to render a HTML page containing it, or a XML formatted result for others to consume.
The View layer is not only limited to HTML or text representation of the data. It can be used to deliver a wide variety of formats depending on your needs, such as videos, music, documents and any other format you can think of.
The Controller layer
The Controller layer handles requests from users. It is responsible for rendering a response with the aid of both the Model and the View layer.
A controller can be seen as a manager that ensures that all resources needed for completing a task are delegated to the correct workers. It waits for petitions from clients, checks their validity according to authentication or authorization rules, delegates data fetching or processing to the model, selects the type of presentational data that the clients are accepting, and finally delegates the rendering process to the View layer.
Figure: 1: A typical MVC Request
The typical request cycle starts with a user requesting a page or resource in your application. This request is first processed by a dispatcher which will select the correct controller object to handle it.
Once the request arrives at the controller, it will communicate with the Model layer to process any data-fetching or -saving operation that might be needed. After this communication is over, the controller will proceed to delegate to the correct view object the task of generating output resulting from the data provided by the model.
Finally, when this output is generated, it is immediately rendered to the user.
Almost every request to your application will follow this basic pattern.
Why use MVC? Because it is a tried and true software design pattern that turns an application into a maintainable, modular, rapidly developed package. Crafting application tasks into separate models, views, and controllers makes your application very light on its feet. New features are easily added, and new faces on old features are a snap. The modular and separate design also allows developers and designers to work simultaneously, including the ability to rapidly prototype. Separation also allows developers to make changes in one part of the application without affecting the others.
Spring MVC request life cycle
Let’s see how Spring MVC handles a request. Figure 2 shows the main components involved in handling a request in Spring MVC. The figure is based on the one described in the Spring Framework
forum, with modifications.
Figure 2. Spring MVC request life cycle
The main components and their purposes are as follows:
- Filter: The filter applies to every request.
- Dispatcher servlet: The servlet analyzes the requests and dispatches them to the appropriate controller for processing.
- Common services: The common services will apply to every request to provide supports including i18n, theme, file upload, and so on. Their configuration is defined in the DispatcherServlet’s WebApplicationContext.
- Handler mapping: This maps the request to the handler (a method within a Spring MVC controller class). Since Spring 2.5, in most situations the configuration is not
required because Spring MVC will automatically register theorg.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping class that maps handlers based on HTTP paths expressed through the @RequestMapping annotation at the type or method level within controller classes.
- Handler interceptor: In Spring MVC, you can register interceptors for the handlers for implementing common checking or logic. For example, a handler interceptor can check and ensure that only the handlers can be invoked during office hours.
- Handler exception resolver: In Spring MVC, the HandlerExceptionResolver interface (under the packageorg.springframework.web.servlet) is designed to deal with unexpected exceptions thrown during request processing by handlers.
By default, the DispatcherServlet registers the DefaultHandlerExceptionResolver class (under the packageorg.springframework.web.servlet.mvc.support). This resolver handles certain standard Spring MVC exceptions by setting a specific response status code. You can also implement your own exception handler by annotating a controller method with the @ExceptionHandler annotation and passing in the exception type as the attribute.
- View Resolver: Spring MVC’s ViewResolver interface (under the package org.springframework.web.servlet) supports view resolution based on a logical name returned by the controller. There are many implementation classes to support various view resolving mechanisms. For example, the UrlBasedViewResolver class supports direct resolution of logical names to URLs. The ContentNegotiatingViewResolver class supports dynamic resolving of views depending on the media type supported by the client (such as XML, PDF, JSON, and so on). There also exists a number of implementations to integrate with different view technologies, such as FreeMarker (FreeMarkerViewResolver), Velocity (VelocityViewResolver), and JasperReports (JasperReportsViewResolver).
These descriptions cover only a few commonly used handlers and resolvers. For a full description, please refer to the Spring Framework reference documentation and its Javadoc.
转载请并标注: “本文转载自 linkedkeeper.com ”