英语原文共 11 页，剩余内容已隐藏，支付完成后下载完整资料

1.1 介绍

Spring Web MVC是构建在Servlet API上的最初的Web框架，从一开始就包含在Spring框架中。 正式名称“Spring Web MVC”来自其源模块spring-webmvc的名称，但它通常被称为“Spring MVC”。

与Spring Web MVC并行，Spring Framework 5.0引入了一个反应堆栈，Web框架，其名称Spring WebFlux也基于它的源模块spring-webflux。

1.2．DispatcherServlet

像许多其他Web框架一样，Spring MVC围绕前端控制器模式进行设计，其中中央Servlet DispatcherServlet为请求处理提供共享算法，而实际工作由可配置委托组件执行。 该模型非常灵活，支持多种工作流程。

作为任何Servlet，DispatcherServlet需要根据Servlet规范使用Java配置或在web.xml中进行声明和映射。 DispatcherServlet依次使用Spring配置来发现它在请求映射，查看解析，异常处理等方面所需的委托组件。

1.2.1. 上下文层次结构

DispatcherServlet需要一个WebApplicationContext（一个普通的ApplicationContext的扩展）用于其自己的配置。 WebApplicationContext有一个指向它所关联的ServletContext和Servlet的链接。 它也绑定到ServletContext，以便应用程序可以使用RequestContextUtils上的静态方法查找WebApplicationContext是否需要访问它。

对于具有单个WebApplicationContext的许多应用程序来说，这是简单而充分的。 也可以有一个上下文层次结构，其中一个根WebApplicationContext通过多个DispatcherServlet（或其他Servlet）实例共享，每个实例都有其自己的子WebApplicationContext配置。 有关上下文层次结构功能的更多信息，请参阅ApplicationContext的其他功能。

1.2.2. 特殊实体类型

DispatcherServlet委托特殊的bean来处理请求并呈现适当的响应。 “特殊bean”是指实现WebFlux框架协议的Spring管理的对象实例。 那些通常带有内置合同，但您可以自定义其属性，扩展或替换它们。

1.2.3. Web MVC配置

应用程序可以声明处理请求所需的特殊Bean类型中列出的基础架构Bean。 DispatcherServlet检查每个特殊bean的WebApplicationContext。 如果没有匹配的bean类型，它将回退到DispatcherServlet.properties中列出的默认类型。

在大多数情况下，MVC配置是最好的起点。 它用Java或XML声明所需的bean，并提供更高级别的配置回调API来定制它。

1.2.4. Servlet配置

WebApplicationInitializer是Spring MVC提供的一个接口，它确保您的实现被检测到并自动用于初始化任何Servlet 3容器。 一个名为AbstractDispatcherServletInitializer的WebApplicationInitializer的抽象基类实现使得通过简单重写方法来指定Servlet映射和DispatcherServlet配置的位置来更容易注册DispatcherServlet。

每个过滤器都会根据其具体类型添加一个默认名称，并自动映射到DispatcherServlet。

AbstractDispatcherServletInitializer的isAsyncSupported受保护方法提供了一个位置来启用DispatcherServlet上的异步支持以及映射到它的所有过滤器。 默认情况下，该标志被设置为true。

最后，如果您需要进一步自定义DispatcherServlet本身，则可以覆盖createDispatcherServlet方法。

1.2.5. 处理

DispatcherServlet按如下方式处理请求：

在请求中搜索并绑定WebApplicationContext，作为控制器和进程中其他元素可以使用的属性。

语言环境解析程序绑定到请求以启用进程中的元素来解析处理请求（呈现视图，准备数据等）时要使用的语言环境。如果你不需要区域解析，你不需要它。

主题解析器必须使请求等元素决定使用哪个主题。如果你不使用主题，你可以忽略它。

如果您指定了多部分文件解析器，则将检查请求中的多部分;如果找到多部分，则将请求封装在MultipartHttpServletRequest中，以供进程中的其他元素进一步处理。有关多部分处理的更多信息，请参阅多部分解析器。

搜索适当的处理程序。如果找到处理程序，则会执行与处理程序（预处理程序，后处理程序和控制器）关联的执行链以准备模型或渲染。或者，对于注释的控制器，响应可以呈现（在HandlerAdapter内）而不是返回视图。

如果返回模型，则呈现视图。如果没有返回模型（可能是由于预处理程序或后处理程序拦截了请求，可能出于安全原因），则不会呈现视图，因为请求可能已经被满足。

WebApplicationContext中声明的HandlerExceptionResolver bean用于解决请求处理期间抛出的异常。这些异常解析器允许定制逻辑来解决异常。有关更多详情，请参阅例外。

Spring DispatcherServlet还支持返回最后修改日期，正如Servlet API所指定的那样。确定特定请求的最后修改日期的过程很简单：DispatcherServlet查找适当的处理程序映射并测试找到的处理程序是否实现LastModified接口。如果是这样，则LastModified接口的long getLastModified（request）方法的值将返回给客户端。

您可以通过将Servlet初始化参数（init-param元素）添加到web.xml文件中的Servlet声明来自定义单个DispatcherServlet实例。请参阅下表以获取支持的参数列表。

1.2.6。拦截

所有HandlerMapping实现都支持处理程序拦截器，当您想要将特定功能应用于某些请求时（例如，检查委托人），该拦截器非常有用。拦截器必须使用三种方法来实现org.springframework.web.servlet包中的HandlerInterceptor，这些方法应该提供足够的灵活性来执行各种预处理和后处理：

preHandle（..） - 在执行实际处理程序之前

postHandle（..） - 处理程序执行后

afterCompletion（..） - 在完成请求完成后

preHandle（..）方法返回一个布尔值。您可以使用此方法来中断或继续处理执行链。当此方法返回true时，处理程序执行链将继续;当它返回false时，DispatcherServlet假定拦截器本身已经处理请求（并且例如呈现适当的视图）并且不继续执行执行链中的其他拦截器和实际处理器。

有关如何配置拦截器的示例，请参阅MVC配置一节中的拦截器。您也可以通过单个HandlerMapping实现上的setter直接注册它们。

请注意，postHandle对于在HandlerAdapter和postHandle之前写入和提交响应的@ResponseBody和ResponseEntity方法不太有用。这意味着对响应进行任何更改都为时已晚，例如添加额外的标题。对于这种场景，您可以实现ResponseBodyAdvice，并将其声明为Controller Advice bean或直接在RequestMappingHandlerAdapter上进行配置。

1.2.7。异常

如果在请求映射期间发生异常或从请求处理程序（如@Controller）抛出异常，则DispatcherServlet委托HandlerExceptionResolver bean链来解决异常并提供替代处理，这通常是错误响应。

解析器链

您可以通过在Spring配置中声明多个HandlerExceptionResolver bean并根据需要设置它们的顺序属性来形成异常解析链。 order属性越高，异常解析器定位的越晚。

HandlerExceptionResolver的合约指定它可以返回：

指向错误视图的ModelAndView。

如果在解析器中处理异常，则为Empty ModelAndView。

如果异常未解决，则返回null，供后续解析器尝试使用;如果异常仍然在最后，它可以冒泡到Servlet容器。

MVC Config自动为默认的Spring MVC异常声明内置的解析器，为@ResponseStatus注释的异常声明和支持@ExceptionHandler方法。您可以自定义该列表或将其替换。

容器错误页面

如果任何HandlerExceptionResolver未解决异常并因此传播，或者响应状态设置为错误状态（即4xx，5xx），则Servlet容器可能会在HTML中呈现默认错误页面。

鉴于上述情况，当异常冒泡时，或者响应具有错误状态时，Servlet容器在容器内将ERROR分派到配置的URL（例如“/ error”）。 然后由DispatcherServlet处理，可能将其映射到一个@Controller，该实现可以通过模型返回一个错误视图名称或呈现JSON响应

1.2.8 查看分辨率

Spring MVC定义了ViewResolver和View接口，使您可以在浏览器中呈现模型，而无需将您绑定到特定的视图技术。 ViewResolver提供了视图名称和实际视图之间的映射。 View在交付给特定视图技术之前处理数据的准备。

通过声明多个解析器bean来链接视图解析器，并在必要时通过设置order属性来指定排序。 请记住，订单属性越高，视图解析器在链中的位置越晚。

ViewResolver的合约指定它可以返回null来指示无法找到视图。 但是，对于JSP和InternalResourceViewResolver，确定JSP是否存在的唯一方法是通过RequestDispatcher执行分派。 因此，必须始终将InternalResourceViewResolver配置为视图解析程序的整体顺序中的最后一个。

配置视图分辨率就像将ViewResolver bean添加到Spring配置一样简单。 MVC Config为View Resolvers提供了一个专用的配置API，并且还用于添加无逻辑的View Controller，这些View Controller无需控制器逻辑即可用于HTML模板渲染。

重定向

视图名称中的特殊重定向：前缀允许您执行重定向。 UrlBasedViewResolver（和子类）将此识别为需要重定向的指令。 视图名称的其余部分是重定向URL。

实际效果与控制器返回RedirectView的效果相同，但现在控制器本身可以简单地按逻辑视图名称操作。 逻辑视图名称（如redirect：/ myapp / some / resource）将相对于当前的Servlet上下文重定向，而名称（如redirect：http：//myhost.com/some/arbitrary/path）将重定向到绝对URL。

请注意，如果控制器方法使用@ResponseStatus进行注释，则注释值优先于RedirectView设置的响应状态。

转发

对于最终由UrlBasedViewResolver和子类解析的视图名称，也可以使用特殊的forward：前缀。 这会创建一个执行RequestDispatcher.forward（）的InternalResourceView。 因此，对于InternalResourceViewResolver和InternalResourceView（对于JSP），此前缀不起作用，但如果使用其他视图技术，但仍希望强制转发资源以由Servlet / JSP引擎处理，可能会有所帮助。 请注意，您也可以链接多个视图解析器。

内容协商

ContentNegotiatingViewResolver不会自行解析视图，而是委托给其他视图解析器，并选择类似于客户端请求的视图。该表示可以从Accept报头或查询参数确定，例如， “/路径？格式= PDF”。

ContentNegotiatingViewResolver通过将请求媒体类型与ViewResolvers关联的View支持的媒体类型（也称为Content-Type）进行比较来选择适当的View来处理请求。具有兼容Content-Type的列表中的第一个视图将表示返回给客户端。如果ViewResolver链无法提供兼容视图，则会查看通过DefaultViews属性指定的视图列表。后一个选项适用于单例视图，该视图可以呈现当前资源的适当表示，而不管逻辑视图名称如何。 Accept头可能包含通配符，例如text / *，在这种情况下，其内容类型为text / xml的View是兼容匹配。

有关配置详细信息，请参阅MVC配置下的查看解析器。

1.2.9语言环境

Spring的架构大

剩余内容已隐藏，支付完成后下载完整资料

资料编号：[609289]，资料为PDF文档或Word文档，PDF文档可免费转换为Word