1.1 Tracking Spring MVC requests
Whenever a user clicks a link or submits a form in a web browser, the request starts working. The job description for the request is like a courier delivery person. Like a post office delivery person or FedEx delivery person, a request takes information from one place to another. Request is a very busy guy. From leaving the browser to getting the response back, it will go through many stops, leaving some information at each stop and bringing other information along. Figure 5.1 shows all the sites a request goes through using Spring MVC.
When the request leaves the browser, it will carry information about what the user requested, at least the requested URL. But there may also be other information, such as form information submitted by the user. The first stop on the request journey is Spring's DispatcherServlet. Like most Java-based web frameworks, all requests in Spring MVC go through a front controller servlet. A front controller is a common web application pattern where a single-instance servlet delegates requests to other components of the application to perform the actual processing. In Spring MVC, DispatcherServlet is the front controller. The task of the DispatcherServlet is to send the request to the Spring MVC controller. A controller is a Spring component that handles requests. In a typical application there may be multiple controllers and the DispatcherServlet needs to know which controller the request should be sent to. So DispatcherServlet will check
One or more handler mappings are queried to determine where the next stop for the request is. The processor mapping will make decisions based on the URL information carried by the request. Once the appropriate controller is selected, the DispatcherServlet will send the request to the selected controller. When it comes to the controller, the request offloads its load (the information submitted by the user) and waits patiently for the controller to process that information. (In reality, a well-designed controller handles little to no work by itself, but instead delegates the business logic to one or more service objects for processing.)
After the controller completes the logic processing, it usually generates some information, which needs to be returned to the user and displayed on the browser. This information is called a model. But it's not enough to just return raw information to the user - the information needs to be formatted in a user-friendly way, usually HTML. So, the information needs to be sent to a view, usually a JSP. The last thing the controller does is package the model data and mark the view name for the rendered output. It next sends the request back to the DispatcherServlet along with the model and view names. In this way, the controller is not coupled to a specific view, and the view name passed to the DispatcherServlet does not directly refer to a specific JSP. In fact, it doesn't even determine that the view is a JSP. Instead, it's just passed a logical name that will be used to find the actual view that produces the result. The DispatcherServlet will use the view resolver to match the logical view name to a specific view implementation, which may or may not be a JSP.
Now that the DispatcherServlet already knows which view to render the result, the requested task is basically done. Its last stop is the implementation of the view (probably a JSP), where it delivers the model data. The requested task is completed. The view will render output using the model data, and this output will be passed to the client via the response object (not hardcoded as it sounds). As you can see, the request goes through many steps before finally forming a response . Most of the steps are done inside the Spring framework, in the components shown in Figure 5.1. Although the bulk of this chapter focuses on how to write controllers, before
Let's first look at how to build the basic components of Spring MVC.
1.2 Building Spring MVC
Configure DispatcherServlet
DispatcherServlet是Spring MVC的核心。在这里请求会第一次接触到框架，它要负责将请求路由到其他的组件之中。按照传统的方式，像DispatcherServlet这样的Servlet会配置在web.xml文件中，这个文件会放到应用的WAR包里面。当然，这是配置DispatcherServlet的方法之一。但是，借助于Servlet 3规范和Spring 3.1的功能增强，这种方式已经不是唯一的方案了，这也不是我们本章所使用的配置方法。我们会使用Java将DispatcherServlet配置在Servlet容器中，而不会再使用web.xml文件。如下的程序清单展示了所需的Java类
Spring MVC配置的替代方案
在web.xml中声明DispatcherServlet
在典型的Spring MVC应用中，我们会需要DispatcherServlet和Context-LoaderListener。AbstractAnnotationConfigDispatcherServletInitializer会自动注册它们，但是如果需要在web.xml中注册的话，那就需要我们自己来完成这项任务了。如下是一个基本的web.xml文件，它按照传统的方式搭建了DispatcherServlet和ContextLoaderListener。
在web.xml中搭建Spring MVC
ContextLoaderListener和DispatcherServlet各自都会加载一个Spring应用上下文。上下文参数contextConfigLocation指定了一个XML文件的地址，这个文件定义了根应用上下文，它会被ContextLoaderListener加载。如程序清单7.3所示，根上下文会从“/WEB-INF/spring/root-context.xml”中加载bean定义。DispatcherServlet会根据Servlet的名字找到一个文件，并基于该文件加载应用上下文。在程序清单7.3中，Servlet的名字是appServlet，因此DispatcherServlet会从“/WEB-INF/appServlet-context.xml”文件中加载其应用上下文。
如果你希望指定DispatcherServlet配置文件的位置的话，那么可以在Servlet上指定一个contextConfigLocation初始化参数。例如，如下的配置中，DispatcherServlet会从“/WEB-INF/spring/appServlet/servlet-context.xml”加载它的bean：
1.3处理multipart形式的数据
multipart格式的数据会将一个表单拆分为多个部分（part），每个部分对应一个输入域。在一般的表单输入域中，它所对应的部分中会放置文本型数据，但是如果上传文件的话，它所对应的部分可以是二进制，下面展现了multipart的请求体：
尽管multipart请求看起来很复杂，但在Spring MVC中处理它们却很容易。在编写控制器方法处理文件上传之前，我们必须要配置一个multipart解析器，通过它来告诉DispatcherServlet该如何读取multipart请求。
配置multipart解析器
DispatcherServlet并没有实现任何解析multipart请求数据的功能。它将该任务委托给了Spring中MultipartResolver策略接口的实现，通过这个实现类来解析multipart请求中的内容。从Spring 3.1开始，Spring内置了两个MultipartResolver的实现供我们选择：CommonsMultipartResolver：使用Jakarta CommonsFileUpload解析multipart请求；StandardServletMultipartResolver：依赖于Servlet 3.0对multipart请求的支持（始于Spring 3.1）。一般来讲，在这两者之间，StandardServletMultipartResolver可能会是优选的方案。它使用Servlet所提供的功能支持，并不需要依赖任何其他的项目。如果我们需要将应用部署到Servlet 3.0之前的容器中，或者还没有使用Spring 3.1或更高版本，那么可能就需要CommonsMultipartResolver了。