View Resolution

Spring MVC定义了`ViewResolver`和`View`接口，可让你在浏览器中呈现模型，而无需限制到特定的视图技术。`ViewResolver`提供视图名称和实际视图之间的映射。`View`解决在移交到特定视图技术之前对数据进行准备的问题。

Spring MVC defines the ViewResolver and View interfaces that let you render models in a browser without tying you to a specific view technology. ViewResolver provides a mapping between view names and actual views. View addresses the preparation of data before handing over to a specific view technology.

下表提供了`ViewResolver`层次结构的更多详细信息：

The following table provides more details on the ViewResolver hierarchy:

Table 1. ViewResolver implementations
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 effects the direct resolution of logical view names to URLs without an explicit mapping definition. This is appropriate if your logical names match the names of your view resources in a straightforward manner, without the need for arbitrary mappings.
`InternalResourceViewResolver`	Convenient subclass of `UrlBasedViewResolver` that supports `InternalResourceView` (in effect, Servlets and JSPs) and subclasses such as `JstlView`. You can specify the view class for all views generated by this resolver by using `setViewClass(..)`. See the `UrlBasedViewResolver` javadoc for details.
`FreeMarkerViewResolver`	Convenient subclass of `UrlBasedViewResolver` that supports `FreeMarkerView` and custom subclasses of them.
`ContentNegotiatingViewResolver`	Implementation of the `ViewResolver` interface that resolves a view based on the request file name or `Accept` header. See Content Negotiation.
`BeanNameViewResolver`	Implementation of the `ViewResolver` interface that interprets a view name as a bean name in the current application context. This is a very flexible variant which allows for mixing and matching different view types based on distinct view names. Each such `View` can be defined as a bean e.g. in XML or in configuration classes.

Handling

你可以通过声明多个解析器 Bean 来链接视图解析器，如需，可以通过设置`order`属性来指定排序。请记住，排序属性的值越高，视图解析器在链中的位置就越靠后。

You can chain view resolvers by declaring more than one resolver bean and, if necessary, by setting the order property to specify ordering. Remember, the higher the order property, the later the view resolver is positioned in the chain.

ViewResolver 的契约规定，它可以返回 null 以表明无法找到视图。但是，对于 JSP 和 InternalResourceViewResolver，找出 JSP 是否存在的唯一方法是通过`RequestDispatcher`执行调度。因此，你必须始终将`InternalResourceViewResolver`配置为视图解析器的整体顺序中的最后一个。

The contract of a ViewResolver specifies that it can return null to indicate that the view could not be found. However, in the case of JSPs and InternalResourceViewResolver, the only way to figure out if a JSP exists is to perform a dispatch through RequestDispatcher. Therefore, you must always configure an InternalResourceViewResolver to be last in the overall order of view resolvers.

配置视图解析与向您的 Spring 配置添加 ViewResolver Bean 一样简单。MVC Config 为 View Resolvers 提供了一个专门的配置 API，并用于添加无逻辑 View Controllers，它们对于在没有控制器逻辑的情况下进行 HTML 模板渲染非常有用。

Configuring view resolution is as simple as adding ViewResolver beans to your Spring configuration. The MVC Config provides a dedicated configuration API for View Resolvers and for adding logic-less View Controllers which are useful for HTML template rendering without controller logic.

Redirecting

视图名称中的特殊`redirect:`前缀使你可以执行重定向。UrlBasedViewResolver（及其子类）将这识别为需要重定向的说明。视图名称的其余部分是重定向 URL。

The special redirect: prefix in a view name lets you perform a redirect. The UrlBasedViewResolver (and its subclasses) recognize this as an instruction that a redirect is needed. The rest of the view name is the redirect URL.

其最终效果与控制器已返回`RedirectView`相同，但现在控制器本身可以根据逻辑视图名称进行操作。逻辑视图名称（比如`redirect:/myapp/some/resource`）相对于当前 Servlet 上下文重定向，而`redirect:https://myhost.com/some/arbitrary/path`这样的名称则重定向到绝对 URL。

The net effect is the same as if the controller had returned a RedirectView, but now the controller itself can operate in terms of logical view names. A logical view name (such as redirect:/myapp/some/resource) redirects relative to the current Servlet context, while a name such as redirect:https://myhost.com/some/arbitrary/path redirects to an absolute URL.

Forwarding

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

You can also use a special forward: prefix for view names that are ultimately resolved by UrlBasedViewResolver and subclasses. This creates an InternalResourceView, which does a RequestDispatcher.forward(). Therefore, this prefix is not useful with InternalResourceViewResolver and InternalResourceView (for JSPs), but it can be helpful if you use another view technology but still want to force a forward of a resource to be handled by the Servlet/JSP engine. Note that you may also chain multiple view resolvers, instead.

Content Negotiation

ContentNegotiatingViewResolver 自身不会解析视图，而是将任务委托给其他视图解析器并选择与客户端请求的表示相似的视图。表示可以从 Accept 头部或查询参数（例如 "/path?format=pdf"）中确定。

ContentNegotiatingViewResolver does not resolve views itself but rather delegates to other view resolvers and selects the view that resembles the representation requested by the client. The representation can be determined from the Accept header or from a query parameter (for example, "/path?format=pdf").

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

The ContentNegotiatingViewResolver selects an appropriate View to handle the request by comparing the request media types with the media type (also known as Content-Type) supported by the View associated with each of its ViewResolvers. The first View in the list that has a compatible Content-Type returns the representation to the client. If a compatible view cannot be supplied by the ViewResolver chain, the list of views specified through the DefaultViews property is consulted. This latter option is appropriate for singleton Views that can render an appropriate representation of the current resource regardless of the logical view name. The Accept header can include wildcards (for example text/*), in which case a View whose Content-Type is text/xml is a compatible match.

有关配置详细信息，请参见 MVC Config 下的 View Resolvers。

See View Resolvers under MVC Config for configuration details.