SpringMVC視圖解析器

前言

在前一篇部落格中講了SpringMVC的Controller控制器，在這篇部落格中将接着介紹一下SpringMVC視圖解析器。當我們對SpringMVC控制的資源發起請求時，這些請求都會被SpringMVC的DispatcherServlet處理，接着Spring會分析看哪一個HandlerMapping定義的所有請求映射中存在對該請求的最合理的映射。然後通過該HandlerMapping取得其對應的Handler，接着再通過相應的HandlerAdapter處理該Handler。HandlerAdapter在對Handler進行處理之後會傳回一個ModelAndView對象。在獲得了ModelAndView對象之後，Spring就需要把該View渲染給使用者，即傳回給浏覽器。在這個渲染的過程中，發揮作用的就是ViewResolver和View。當Handler傳回的ModelAndView中不包含真正的視圖，隻傳回一個邏輯視圖名稱的時候，ViewResolver就會把該邏輯視圖名稱解析為真正的視圖View對象。View是真正進行視圖渲染，把結果傳回給浏覽器的。

ViewResolver和View介紹

SpringMVC用于處理視圖最重要的兩個接口是ViewResolver和View。ViewResolver的主要作用是把一個邏輯上的視圖名稱解析為一個真正的視圖，SpringMVC中用于把View對象呈現給用戶端的是View對象本身，而ViewResolver隻是把邏輯視圖名稱解析為對象的View對象。View接口的主要作用是用于處理視圖，然後傳回給用戶端。

Spring為我們提供了非常多的視圖解析器，下面将列舉一些視圖解析器。

AbstractCachingViewResolver：這是一個抽象類，這種視圖解析器會把它曾經解析過的視圖儲存起來，然後每次要解析視圖的時候先從緩存裡面找，如果找到了對應的視圖就直接傳回，如果沒有就建立一個新的視圖對象，然後把它放到一個用于緩存的map中，接着再把建立的視圖傳回。使用這種視圖緩存的方式可以把解析視圖的性能問題降到最低。

UrlBasedViewResolver：它是對ViewResolver的一種簡單實作，而且繼承了AbstractCachingViewResolver，主要就是提供的一種拼接URL的方式來解析視圖，它可以讓我們通過prefix屬性指定一個指定的字首，通過suffix屬性指定一個指定的字尾，然後把傳回的邏輯視圖名稱加上指定的字首和字尾就是指定的視圖URL了。如prefix=/WEB-INF/jsps/，suffix=.jsp，傳回的視圖名稱viewName=test/indx，則UrlBasedViewResolver解析出來的視圖URL就是/WEB-INF/jsps/test/index.jsp。預設的prefix和suffix都是空串。URLBasedViewResolver支援傳回的視圖名稱中包含redirect:字首，這樣就可以支援URL在用戶端的跳轉，如當傳回的視圖名稱是”redirect:test.do”的時候，URLBasedViewResolver發現傳回的視圖名稱包含”redirect:”字首，于是把傳回的視圖名稱字首”redirect:”去掉，取後面的test.do組成一個RedirectView，RedirectView中将把請求傳回的模型屬性組合成查詢參數的形式組合到redirect的URL後面，然後調用HttpServletResponse對象的sendRedirect方法進行重定向。同樣URLBasedViewResolver還支援forword:字首，對于視圖名稱中包含forword:字首的視圖名稱将會被封裝成一個InternalResourceView對象，然後在伺服器端利用RequestDispatcher的forword方式跳轉到指定的位址。使用UrlBasedViewResolver的時候必須指定屬性viewClass，表示解析成哪種視圖，一般使用較多的就是InternalResourceView，利用它來展現jsp，但是當我們使用JSTL的時候我們必須使用JstlView。下面是一段UrlBasedViewResolver的定義，根據該定義，當傳回的邏輯視圖名稱是test的時候，UrlBasedViewResolver将把邏輯視圖名稱加上定義好的字首和字尾，即“/WEB-INF/test.jsp”，然後建立一個viewClass屬性指定的視圖類型予以傳回，即傳回一個url為“/WEB-INF/test.jsp”的InternalResourceView對象。

Xml代碼

<bean

class="org.springframework.web.servlet.view.UrlBasedViewResolver">

</bean>

InternalResourceViewResolver：它是URLBasedViewResolver的子類，是以URLBasedViewResolver支援的特性它都支援。在實際應用中InternalResourceViewResolver也是使用的最廣泛的一個視圖解析器。那麼InternalResourceViewResolver有什麼自己獨有的特性呢？單從字面意思來看，我們可以把InternalResourceViewResolver解釋為内部資源視圖解析器，這就是InternalResourceViewResolver的一個特性。InternalResourceViewResolver會把傳回的視圖名稱都解析為InternalResourceView對象，InternalResourceView會把Controller處理器方法傳回的模型屬性都存放到對應的request屬性中，然後通過RequestDispatcher在伺服器端把請求forword重定向到目标URL。比如在InternalResourceViewResolver中定義了prefix=/WEB-INF/，suffix=.jsp，然後請求的Controller處理器方法傳回的視圖名稱為test，那麼這個時候InternalResourceViewResolver就會把test解析為一個InternalResourceView對象，先把傳回的模型屬性都存放到對應的HttpServletRequest屬性中，然後利用RequestDispatcher在伺服器端把請求forword到/WEB-INF/test.jsp。這就是InternalResourceViewResolver一個非常重要的特性，我們都知道存放在/WEB-INF/下面的内容是不能直接通過request請求的方式請求到的，為了安全性考慮，我們通常會把jsp檔案放在WEB-INF目錄下，而InternalResourceView在伺服器端跳轉的方式可以很好的解決這個問題。下面是一個InternalResourceViewResolver的定義，根據該定義當傳回的邏輯視圖名稱是test的時候，InternalResourceViewResolver會給它加上定義好的字首和字尾，組成“/WEB-INF/test.jsp”的形式，然後把它當做一個InternalResourceView的url建立一個InternalResourceView對象傳回。

XmlViewResolver：它繼承自AbstractCachingViewResolver抽象類，是以它也是支援視圖緩存的。XmlViewResolver需要給定一個xml配置檔案，該檔案将使用和Spring的bean工廠配置檔案一樣的DTD定義，是以其實該檔案就是用來定義視圖的bean對象的。在該檔案中定義的每一個視圖的bean對象都給定一個名字，然後XmlViewResolver将根據Controller處理器方法傳回的邏輯視圖名稱到XmlViewResolver指定的配置檔案中尋找對應名稱的視圖bean用于處理視圖。該配置檔案預設是/WEB-INF/views.xml檔案，如果不使用預設值的時候可以在XmlViewResolver的location屬性中指定它的位置。XmlViewResolver還實作了Ordered接口，是以我們可以通過其order屬性來指定在ViewResolver鍊中它所處的位置，order的值越小優先級越高。以下是使用XmlViewResolver的一個示例：

（1）在SpringMVC的配置檔案中加入XmlViewResolver的bean定義。使用location屬性指定其配置檔案所在的位置，order屬性指定當有多個ViewResolver的時候其處理視圖的優先級。關于ViewResolver鍊的問題将在後續内容中講到。

（2）在XmlViewResolver對應的配置檔案中配置好所需要的視圖定義。在下面的代碼中我們就配置了一個名為internalResource的InternalResourceView，其url屬性為“/index.jsp”。

<?xml version="1.0" encoding="UTF-8"?>

<beans xmlns="http://www.springframework.org/schema/beans"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-3.0.xsd">

</bean>

</beans>

（3）定義一個傳回的邏輯視圖名稱為在XmlViewResolver配置檔案中定義的視圖名稱——internalResource。

Java代碼

@RequestMapping("/xmlViewResolver")

public String testXmlViewResolver() {

return "internalResource";

}

（4）這樣當我們通路到上面定義好的testXmlViewResolver處理器方法的時候傳回的邏輯視圖名稱為“internalResource”，這時候Spring就會到定義好的views.xml中尋找id或name為“internalResource”的bean對象予以傳回，這裡Spring找到的是一個url為“/index.jsp”的InternalResourceView對象。

BeanNameViewResolver：這個視圖解析器跟XmlViewResolver有點類似，也是通過把傳回的邏輯視圖名稱去比對定義好的視圖bean對象。不同點有二，一是BeanNameViewResolver要求視圖bean對象都定義在Spring的application context中，而XmlViewResolver是在指定的配置檔案中尋找視圖bean對象，二是BeanNameViewResolver不會進行視圖緩存。看一個例子，在SpringMVC的配置檔案中定義了一個BeanNameViewResolver視圖解析器和一個id為test的InternalResourceview bean對象。

這樣當傳回的邏輯視圖名稱是 test的時候，就會解析為上面定義好id為test的InternalResourceView。

ResourceBundleViewResolver：它和XmlViewResolver一樣，也是繼承自AbstractCachingViewResolver，但是它緩存的不是視圖，這個會在後面有說到。和XmlViewResolver一樣它也需要有一個配置檔案來定義邏輯視圖名稱和真正的View對象的對應關系，不同的是ResourceBundleViewResolver的配置檔案是一個屬性檔案，而且必須是放在classpath路徑下面的，預設情況下這個配置檔案是在classpath根目錄下的views.properties檔案，如果不使用預設值的話，則可以通過屬性baseName或baseNames來指定。baseName隻是指定一個基名稱，Spring會在指定的classpath根目錄下尋找以指定的baseName開始的屬性檔案進行View解析，如指定的baseName是base，那麼base.properties、baseabc.properties等等以base開始的屬性檔案都會被Spring當做ResourceBundleViewResolver解析視圖的資源檔案。ResourceBundleViewResolver使用的屬性配置檔案的内容類似于這樣：

Properties代碼

resourceBundle.(class)=org.springframework.web.servlet.view.InternalResourceView

resourceBundle.url=/index.jsp

test.(class)=org.springframework.web.servlet.view.InternalResourceView

test.url=/test.jsp

在這個配置檔案中我們定義了兩個InternalResourceView對象，一個的名稱是resourceBundle，對應URL是/index.jsp，另一個名稱是test，對應的URL是/test.jsp。從這個定義來看我們可以知道resourceBundle是對應的視圖名稱，使用resourceBundle.(class)來指定它對應的視圖類型，resourceBundle.url指定這個視圖的url屬性。會思考的讀者看到這裡可能會有這樣一個問題：為什麼resourceBundle的class屬性要用小括号包起來，而它的url屬性就不需要呢？這就需要從ResourceBundleViewResolver進行視圖解析的方法來說了。ResourceBundleViewResolver還是通過bean工廠來獲得對應視圖名稱的視圖bean對象來解析視圖的。那麼這些bean從哪裡來呢？就是從我們定義的properties屬性檔案中來。在ResourceBundleViewResolver第一次進行視圖解析的時候會先new一個BeanFactory對象，然後把properties檔案中定義好的屬性按照它自身的規則生成一個個的bean對象注冊到該BeanFactory中，之後會把該BeanFactory對象儲存起來，是以ResourceBundleViewResolver緩存的是BeanFactory，而不是直接的緩存從BeanFactory中取出的視圖bean。然後會從bean工廠中取出名稱為邏輯視圖名稱的視圖bean進行傳回。接下來就講講Spring通過properties檔案生成bean的規則。它會把properties檔案中定義的屬性名稱按最後一個點“.”進行分割，把點前面的内容當做是bean名稱，點後面的内容當做是bean的屬性。這其中有幾個特别的屬性，Spring把它們用小括号包起來了，這些特殊的屬性一般是對應的attribute，但不是bean對象所有的attribute都可以這樣用。其中(class)是一個，除了(class)之外，還有(scope)、(parent)、(abstract)、(lazy-init)。而除了這些特殊的屬性之外的其他屬性，Spring會把它們當做bean對象的一般屬性進行處理，就是bean對象對應的property。是以根據上面的屬性配置檔案将生成如下兩個bean對象：

從ResourceBundleViewResolver使用的配置檔案我們可以看出，它和XmlViewResolver一樣可以解析多種不同類型的View，因為它們的View是通過配置的方式指定的，這也就意味着我們可以指定A視圖是InternalResourceView，B視圖是JstlView。

來看下面這個一個例子，我在SpringMVC的配置檔案中定義了一個ResourceBundleViewResolver對象，指定其baseName為views，然後order為1。

我在classpath的根目錄下有兩個屬性檔案，一個是views.properties，一個是views_abc.properties，它們的内容分别如下：

views.properties：

views_abc.properties：

abc.(class)=org.springframework.web.servlet.view.InternalResourceView

abc.url=/abc.jsp

定義了如下這樣一個Controller，它有三個處理器方法。

@Controller

@RequestMapping("/mytest")

public class MyController {

@RequestMapping("resourceBundle")

public String resourceBundle() {

return "resourceBundle";

}

@RequestMapping("testResourceBundle")

public String testResourceBundle() {

return "test";

@RequestMapping("abc")

public String abc() {

return "abc";

那麼當我們請求/mytest/resourceBundle.do的時候，ResourceBundleViewResolver會首先嘗試着來解析該視圖，這裡Controller處理器方法傳回的邏輯視圖名稱是resourceBundle，ResourceBundleViewResolver按照上面提到的解析方法進行解析，這個時候它發現它是可以解析的，然後就傳回了一個url為/index.jsp的InternalResourceView對象。同樣，請求/mytest/testResourceBundle.do傳回的邏輯視圖test和/mytest/abc.do傳回的邏輯視圖abc它都可以解析。當我們把basename指定為包的形式，如“com.tiantian.views”，的時候Spring會按照點“.”劃分為目錄的形式，到classpath相應目錄下去尋找basename開始的配置檔案，如上面我們指定basename為“com.tiantian.views”，那麼spring就會到classpath下的com/tiantian目錄下尋找檔案名以views開始的properties檔案作為解析視圖的配置檔案。

FreeMarkerViewResolver、VolocityViewResolver：這兩個視圖解析器都是UrlBasedViewResolver的子類。FreeMarkerViewResolver會把Controller處理方法傳回的邏輯視圖解析為FreeMarkerView，而VolocityViewResolver會把傳回的邏輯視圖解析為VolocityView。因為這兩個視圖解析器類似，是以這裡我就隻挑FreeMarkerViewResolver來做一個簡單的講解。FreeMarkerViewResolver和VilocityViewResolver都繼承了UrlBasedViewResolver。

對于FreeMarkerViewResolver而言，它會按照UrlBasedViewResolver拼接URL的方式進行視圖路徑的解析。但是使用FreeMarkerViewResolver的時候不需要我們指定其viewClass，因為FreeMarkerViewResolver中已經把viewClass定死為FreeMarkerView了。

我們先在SpringMVC的配置檔案裡面定義一個FreeMarkerViewResolver視圖解析器，并定義其解析視圖的order順序為1。

那麼當我們請求的處理器方法傳回一個邏輯視圖名稱viewName的時候，就會被該視圖處理器加上前字尾解析為一個url為“fm_viewName.ftl”的FreeMarkerView對象。對于FreeMarkerView我們需要給定一個FreeMarkerConfig的bean對象來定義FreeMarker的配置資訊。FreeMarkerConfig是一個接口，Spring已經為我們提供了一個實作，它就是FreeMarkerConfigurer。我們可以通過在SpringMVC的配置檔案裡面定義該bean對象來定義FreeMarker的配置資訊，該配置資訊将會在FreeMarkerView進行渲染的時候使用到。對于FreeMarkerConfigurer而言，我們最簡單的配置就是配置一個templateLoaderPath，告訴Spring應該到哪裡尋找FreeMarker的模闆檔案。這個templateLoaderPath也支援使用“classpath:”和“file:”字首。當FreeMarker的模闆檔案放在多個不同的路徑下面的時候，我們可以使用templateLoaderPaths屬性來指定多個路徑。在這裡我們指定模闆檔案是放在“/WEB-INF/freemarker/template”下面的。

接下來我們定義如下一個Controller：

@RequestMapping("freemarker")

public ModelAndView freemarker() {

ModelAndView mav = new ModelAndView();

mav.addObject("hello", "andy");

mav.setViewName("freemarker");

return mav;

由上面的定義我們可以看到這個Controller的處理器方法freemarker傳回的邏輯視圖名稱是“freemarker”。那麼如果我們需要把該freemarker視圖交給FreeMarkerViewResolver來解析的話，我們就需要根據上面的定義，在模闆路徑下定義視圖對應的模闆，即在“/WEB-INF/freemarker/template”目錄下建立fm_freemarker.ftl模闆檔案。這裡我們定義其内容如下：

Ftl代碼

<html>

<head>

<title>FreeMarker</title>

</head>

<body>

<b>Hello World</b>

<font color="red">Hello World!</font>

${hello}

</body>

</html>

經過上面的定義當我們通路/mytest/freemarker.do的時候就會傳回一個邏輯視圖名稱為“freemarker”的ModelAndView對象，根據定義好的視圖解析的順序，首先進行視圖解析的是FreeMarkerViewResolver，這個時候FreeMarkerViewResolver會試着解析該視圖，根據它自身的定義，它會先解析到該視圖的URL為fm_freemarker.ftl，然後它會看是否能夠執行個體化該視圖對象，即在定義好的模闆路徑下是否有該模闆存在，如果有則傳回該模闆對應的FreeMarkerView。在這裡的話/WEB-INF/freemarker/template目錄下是存在模闆檔案fm_freemarker.ftl的，是以會傳回一個url為fm_freemarker.ftl的FreeMarkerView對象。接着FreeMarkerView就可以利用該模闆檔案進行視圖的渲染了。是以通路結果應該如下所示：

視圖解析器鍊

在SpringMVC中可以同時定義多個ViewResolver視圖解析器，然後它們會組成一個ViewResolver鍊。當Controller處理器方法傳回一個邏輯視圖名稱後，ViewResolver鍊将根據其中ViewResolver的優先級來進行處理。所有的ViewResolver都實作了Ordered接口，在Spring中實作了這個接口的類都是可以排序的。在ViewResolver中是通過order屬性來指定順序的，預設都是最大值。是以我們可以通過指定ViewResolver的order屬性來實作ViewResolver的優先級，order屬性是Integer類型，order越小，對應的ViewResolver将有越高的解析視圖的權利，是以第一個進行解析的将是ViewResolver鍊中order值最小的那個。當一個ViewResolver在進行視圖解析後傳回的View對象是null的話就表示該ViewResolver不能解析該視圖，這個時候如果還存在其他order值比它大的ViewResolver就會調用剩餘的ViewResolver中的order值最小的那個來解析該視圖，依此類推。當ViewResolver在進行視圖解析後傳回的是一個非空的View對象的時候，就表示該ViewResolver能夠解析該視圖，那麼視圖解析這一步就完成了，後續的ViewResolver将不會再用來解析該視圖。當定義的所有ViewResolver都不能解析該視圖的時候，Spring就會抛出一個異常。

基于Spring支援的這種ViewResolver鍊模式，我們就可以在SpringMVC應用中同時定義多個ViewResolver，給定不同的order值，這樣我們就可以對特定的視圖特定處理，以此來支援同一應用中有多種視圖類型。注意：像InternalResourceViewResolver這種能解析所有的視圖，即永遠能傳回一個非空View對象的ViewResolver一定要把它放在ViewResolver鍊的最後面。

轉自：http://haohaoxuexi.iteye.com/blog/1770554

SpringMVC視圖解析器

繼續閱讀

基于Springboot+VUE+Mysql的大學生校園疫情防控管理系統

Using MessageConverter

吃透MVC，馴服爛代碼吃透MVC，馴服爛代碼

馴服爛代碼_C＃中的馴服配置

Spring Cloud整合Sleuth，當請求完成後，Zipkin沒有鍊路資訊

JAVA自學之路——馬士兵

SpringMVC常見注釋的簡述

Rabbitmq指令行手動建立隊列

整合 Spring 開發架構及服務端技術

SSM整合02---Spring-SpringMVC層一、添加web架構支援二、web.xml三、spring-mvc.xml

SSM架構（二）------------表現層的SpringMVC

Intellij idea基于Maven 的SSM 架構整合

Spring資料和Redis

SpringMVC的啟動過程源碼分析1 SpringMVC 配置XML的方式啟動2 SpringMVC純注解模式啟動

Java Spring 架構

SpringCloud微服務（四）之ribbon筆記ribbon是什麼？入門案例自定義均衡負載算法