视图分辨率
Spring MVC定义了ViewResolver和View接口，这些接口允许你在不依赖特定视图技术的情况下在浏览器中渲染模型。ViewResolver提供了视图名称与实际视图之间的映射关系。而View则负责在将数据交给特定视图技术处理之前进行数据的准备工作。
下表提供了关于ViewResolver层次结构的更多详细信息：
表1. ViewResolver实现
| ViewResolver | Description |
|---|---|
AbstractCachingViewResolver | Subclasses of AbstractCachingViewResolver cache view instances that they resolve. Caching improves performance of certain view technologies. You can turn off the cache by setting the cache property to false. Furthermore, if you must refresh a certain view at runtime (for example, when a FreeMarker template is modified), you can use the removeFromCache(String viewName, Locale loc) method. |
UrlBasedViewResolver | Simple implementation of the ViewResolver interface that directly resolves logical view names to URLs without the need for explicit mapping definitions. This is suitable when logical view names directly match the names of your view resources without requiring arbitrary mappings. |
InternalResourceViewResolver | Convenient subclass of UrlBasedViewResolver that supports InternalResourceView (essentially, Servlets and JSPs) as well as subclasses like JstlView. You can specify the view class for all views generated by this resolver using setViewClass(..). For more details, see UrlBasedViewResolver. |
FreeMarkerViewResolver | Convenient subclass of UrlBasedViewResolver that supports FreeMarkerView and its custom subclasses. |
ContentNegotiatingView Resolver | Implementation of the ViewResolver interface that resolves a view based on the request file name or the Accept header. For more information, see Content Negotiation. |
BeanNameViewResolver | Implementation of the ViewResolver interface that interprets a view name as a bean name in the current application context. This flexible approach allows for mixing and matching different view types based on distinct names; each view can be defined as a bean, for example, in XML or configuration classes. |
处理
你可以通过声明多个解析器 bean 来链接视图解析器，如有必要，还可以通过设置 order 属性来指定顺序。请记住，order 属性的值越大，该视图解析器在链中的位置就越靠后。
ViewResolver的契约规定它可以返回null来表示找不到相应的视图。然而，在JSP和InternalResourceViewResolver的情况下，判断一个JSP是否存在唯一的方法是通过RequestDispatcher来进行调度。因此，你必须始终将InternalResourceViewResolver配置在所有视图解析器的最终位置。
配置视图解析非常简单，只需在Spring配置中添加ViewResolverbean即可。MVC Config提供了专门的配置API，用于View Resolvers以及无逻辑的View Controllers，这些对于无需控制器逻辑的HTML模板渲染非常有用。
重定向
在视图名称中，特殊的 redirect: 前缀允许你执行重定向操作。UrlBasedViewResolver（及其子类）会将此识别为需要执行重定向的指令。视图名称的其余部分即为重定向URL。
其净效果就如同控制器返回了一个RedirectView一样，但现在控制器本身能够根据逻辑视图名称来进行操作了。逻辑视图名称（例如redirect:/myapp/some/resource）是相对于当前的Servlet上下文进行重定向的，而像redirect:https://myhost.com/some/arbitrary/path这样的名称则是指向一个绝对URL的。
转发
您也可以为最终由 UrlBasedViewResolver 及其子类处理的视图名称使用特殊的 forward: 前缀。这样会创建一个 InternalResourceView，该视图会执行 RequestDispatcher.forward() 操作。因此，这个前缀对于 InternalResourceViewResolver 和 InternalResourceView（用于 JSP）来说并没有用处，但如果您使用的是其他视图技术，但仍希望强制将资源转发给 Servlet/JSP 引擎处理，那么这个前缀可能会很有帮助。需要注意的是，您也可以链式使用多个视图解析器。
内容协商
ContentNegotiatingViewResolver 并不直接解析视图，而是将任务委托给其他视图解析器，然后选择与客户端请求的表示形式相匹配的视图。该表示形式可以从 Accept 请求头或查询参数中确定（例如，“/path?format=pdf”）。
ContentNegotiatingViewResolver 通过将请求的媒体类型（也称为 Content-Type）与其关联的每个 ViewResolver 所支持的媒体类型进行比较来选择合适的 View 来处理请求。列表中第一个具有兼容 Content-Type 的 View 会向客户端返回相应的响应内容。如果 ViewResolver 链无法提供兼容的视图，则会参考通过 DefaultViews 属性指定的视图列表。这种做法适用于那些无论逻辑视图名称如何都能正确渲染当前资源内容的单例 View。Accept 头部字段可以包含通配符（例如 text/*），在这种情况下，Content-Type 为 text/xml 的 View 就是兼容的匹配项。
有关配置详情，请参阅MVC Config下的View Resolvers。