檢視解析

Spring MVC 定義了 `ViewResolver` 和 `View` 介面,允許您在瀏覽器中渲染模型,而無需繫結到特定的檢視技術。`ViewResolver` 提供了檢視名稱和實際檢視之間的對映。`View` 負責在將資料交給特定檢視技術之前準備資料。

下表提供了關於 `ViewResolver` 層次結構的更多詳細資訊

表 1. ViewResolver 實現
ViewResolver 描述

AbstractCachingViewResolver

`AbstractCachingViewResolver` 的子類會快取它們解析的檢視例項。快取提高了某些檢視技術的效能。您可以透過將 `cache` 屬性設定為 `false` 來關閉快取。此外,如果您必須在執行時重新整理某個檢視(例如,當 FreeMarker 模板被修改時),您可以使用 `removeFromCache(String viewName, Locale loc)` 方法。

UrlBasedViewResolver

`ViewResolver` 介面的簡單實現,它直接將邏輯檢視名稱解析為 URL,無需顯式對映定義。如果您的邏輯名稱以直接的方式與檢視資源的名稱匹配,並且無需任意對映,則這種實現是合適的。

InternalResourceViewResolver

`UrlBasedViewResolver` 的便捷子類,支援 `InternalResourceView`(實際上是 Servlets 和 JSP)以及 `JstlView` 等子類。您可以透過使用 `setViewClass(..)` 為此解析器生成的所有檢視指定檢視類。有關詳細資訊,請參閱 `UrlBasedViewResolver` 的 Javadoc。

FreeMarkerViewResolver

`UrlBasedViewResolver` 的便捷子類,支援 `FreeMarkerView` 及其自定義子類。

ContentNegotiatingViewResolver

`ViewResolver` 介面的實現,根據請求檔名或 `Accept` 頭解析檢視。請參閱 內容協商

BeanNameViewResolver

`ViewResolver` 介面的實現,它將檢視名稱解釋為當前應用上下文中的 bean 名稱。這是一種非常靈活的變體,允許根據不同的檢視名稱混合和匹配不同的檢視型別。每個此類 `View` 都可以定義為一個 bean,例如,在 XML 或配置類中。

處理

您可以透過宣告多個解析器 bean 來鏈式連線檢視解析器,如有必要,可以透過設定 `order` 屬性來指定順序。請記住,`order` 屬性的值越高,檢視解析器在鏈中就越靠後。

`ViewResolver` 的契約規定它可以返回 null,表示找不到檢視。然而,對於 JSP 和 `InternalResourceViewResolver` 的情況,判斷 JSP 是否存在的唯一方法是透過 `RequestDispatcher` 進行分派。因此,您必須始終將 `InternalResourceViewResolver` 配置在所有檢視解析器的最後。

配置檢視解析就像在 Spring 配置中新增 `ViewResolver` bean 一樣簡單。MVC 配置檢視解析器 提供了專門的配置 API,並用於新增無邏輯的 檢視控制器,這對於無需控制器邏輯即可進行 HTML 模板渲染非常有用。

重定向

檢視名稱中的特殊字首 redirect: 允許您執行重定向。UrlBasedViewResolver(及其子類)將其識別為需要重定向的指令。檢視名稱的其餘部分是重定向 URL。

最終效果與控制器返回 RedirectView 相同,但現在控制器本身可以使用邏輯檢視名稱進行操作。邏輯檢視名稱(例如 redirect:/myapp/some/resource)相對於當前 Servlet 上下文進行重定向,而像 redirect:https://myhost.com/some/arbitrary/path 這樣的名稱則重定向到絕對 URL。

轉發

您還可以為最終由 UrlBasedViewResolver 及其子類解析的檢視名稱使用特殊的 forward: 字首。這會建立一個 InternalResourceView,它執行 RequestDispatcher.forward()。因此,此此綴對於 InternalResourceViewResolverInternalResourceView(用於 JSP)沒有用處,但如果您使用其他檢視技術但仍想強制將資源轉發給 Servlet/JSP 引擎處理,則可能很有幫助。請注意,您也可以改為鏈式連線多個檢視解析器。

內容協商

ContentNegotiatingViewResolver 本身不解析檢視,而是委託給其他檢視解析器,並選擇與客戶端請求的表示形式相似的檢視。該表示形式可以從 Accept 頭或查詢引數(例如,"/path?format=pdf")確定。

ContentNegotiatingViewResolver 透過比較請求媒體型別與與其每個 ViewResolvers 關聯的 View 支援的媒體型別(也稱為 Content-Type),來選擇處理請求的適當 View。列表中第一個具有相容 Content-TypeView 將向客戶端返回表示形式。如果 ViewResolver 鏈無法提供相容的檢視,則會查閱透過 DefaultViews 屬性指定的檢視列表。後一種選項適用於那些無論邏輯檢視名稱如何都能渲染當前資源適當表示形式的單例 ViewsAccept 頭可以包含萬用字元(例如 text/*),在這種情況下,Content-Typetext/xmlView 是一個相容的匹配項。

有關配置詳細資訊,請參閱 MVC 配置下的 檢視解析器