文章目錄

• • SpringMVC的自定義視圖解析器
  • • • [1] SpringMVC的視圖解析器
      • [2] SpringMVC的自定義視圖解析器
  • SpringMVC自定義視圖解析器的使用
  • • • [1] 目前項目資源的聲明位置和訪問中存在的問題
      • [2] 使用自定義視圖解析器優(yōu)化資源跳轉路徑
      • [3] 使用restful聲明公共單元方法請求轉發(fā)WEB-INF下的資源

SpringMVC的自定義視圖解析器

[1] SpringMVC的視圖解析器

問題:

我們在使用了SpringMVC后，對于請求的處理由以前我們自己聲明
Servlet處理，變?yōu)槁暶鲉卧椒▉硖幚怼Ｕ埱筇幚硗瓿芍?#xff0c;需要將
處理結果響應給瀏覽器 ，響應方式有直接響應，請求轉發(fā)，重定向。對于
請求轉發(fā)和重定向，我們在單元方法中是通過返回值來告訴 DispatcherServlet如何進行此次請求的響應。而方法的返回值只有一個，所 以，我們就需要在返回值值中聲明指定的關鍵字，讓DispatcherServlet可以
通過關鍵字來區(qū)分是請求轉發(fā)還是重定向，那么DispactherServlet底層是
如何來實現(xiàn)請求轉發(fā)和重定向的區(qū)分的呢？

解決:

在DispatcherServlet的底層，增加邏輯代碼，根據(jù)單元方法的返回值
將其返回值中的forward或者redirect關鍵字拆分出來，然后根據(jù)關鍵字
以及資源路徑，最終完成資源的請求轉發(fā)或者重定向。而這段邏輯代碼
就是根據(jù)單元方法的返回值來完成最終的資源的處理，為了讓Dispatcher
Servlet的代碼結構層次更加清晰，我們可以將這段邏輯代碼專門封裝
起來，然后在DispatcherServlet中進行調用即可。也就意味著單元方法的
返回值被DispatcherServlet接收后，作為實參傳遞給了這段封裝好的邏輯
代碼。

實現(xiàn):

視圖解析器

本質:

視圖解析器就是SpringMVC官方封裝好的，根據(jù)單元方法的返回值
完成對應的請求轉發(fā)或者重定向的對象。由DisatcherServlet來調用。

內容:

InternalResourceView:請求轉發(fā)
RedirectView:重定向
ModelAndView:請求轉發(fā)和重定向

代碼示例:

[2] SpringMVC的自定義視圖解析器

問題:

目前我們在SpringMVC的響應中，雖然我們直接在單元方法中返回字符串數(shù)據(jù)來
表明請求轉發(fā)或者重定向的資源，但是DispatcherServlet的底層默認使用 ModelAndView來完成視圖資源的解析和跳轉。但是ModelAndView這個視圖 解析器比較死板，ModelAndView會將單元方法返回的字符串，根據(jù)關鍵拆分后
來完成資源的跳轉，比如:”forward:/index.jsp”,那么ModelAndView就會直接
請求轉發(fā)index.jsp資源。但是我們在實際生產環(huán)境中往往會有很多特殊的需求，
這樣ModelAndView就無法滿足了，比如，我們在項目下創(chuàng)建一個a文件夾，在
a文件夾下創(chuàng)建b子文件夾，在b下創(chuàng)建一個c子文件夾，然后將項目的頁面資 源全部放到c文件夾下，這樣我們如果在單元方法中請求轉發(fā)c文件夾中的資源，
返回值路徑就會很麻煩：
”forward:/a/b/c/index.jsp”
”forward:/a/b/c/page.jsp”
“forward:/a/b/c/sel.jsp”…
而且后期一旦資源路徑的文件夾名字發(fā)生變更，修改起來也會非常的麻煩。

解決:

使用自定義視圖解析器，而我們自定義的視圖解析器除了可以讓我們根據(jù)需求
配置一些路徑上的常量參數(shù)以外，還需具備ModelAndView的邏輯。所以，
我們自己需要從頭創(chuàng)建一個新的視圖解析器，在我們自己創(chuàng)建的視圖解析器中
聲明ModelAndView中的原有邏輯代碼，以及我們自己需要的部分常量參數(shù)。
但是ModelAndView的邏輯我們是不知道的，那么能不能讓SpringMVC官方
提供一個支持部分數(shù)據(jù)自定義的視圖解析器呢，答案是可以的。我們可以通過配置 文件來配置一些我們在視圖解析器中的常量數(shù)據(jù)。

實現(xiàn):

InternalResourceViewResolver

概念:

因為InternalResourceViewResolver可以讓我們通過配置文件來設置一些常量
參數(shù)，所以我們將該視圖解析器稱為自定義視圖解析器。

使用:

在springmvc.xml文件中進行配置

在單元方法中按照指定的格式返回資源路徑

代碼示例:
SpringMVC.xml的配置

測試單元方法示例代碼:

SpringMVC自定義視圖解析器的使用

[1] 目前項目資源的聲明位置和訪問中存在的問題

問題:

目前我們在完成功能開發(fā)時，會將項目相關的頁面資源及靜態(tài)資源直接聲明
在web目錄下，或者web目錄下的子文件夾中。而web目錄及其聲明的子
目錄中的資源，在瀏覽器中是可以直接被訪問到的。也就是說，只要我們知道
某個資源的URL地址，在瀏覽器中是可以直接發(fā)起請求訪問該資源的，極不安全。

解決:

假如有一天你變得很有錢，為了將錢進行保值，你就將錢都買成了古董。我們將
買的古董放在家里的客廳里面，但是我們的朋友只要知道家里的地址，就可以過來
把玩古董。后來因為客廳的古董實在是太多了，于是呢，我們將古董放在了廂房中
一部分。而廂房我們也是對外開放的，也就說朋友來了，可以直接進入廂房來把玩。
但是對于一些非常重要的古董，我們希望不能直接對外進行開放，將它們給隱藏
起來。這樣有朋友來了，我們可以根據(jù)這位朋友的人品，來決定是否讓他來欣賞
重要的古董。如果我們覺得不靠譜，就算朋友知道我們有該古董，但是我們仍然是
可以拒絕的，說我沒有這個東東。假如靠譜，我們可以將古董從密室中拿出來給
朋友欣賞。也就是說，我們放在密室中的古董，我們自己是可以把控這些古董的訪 問權限的。而客廳和廂房中的我們無法把控，因為只要朋友來了就可以直接訪問。

實現(xiàn)方案:

在我們的web項目中造一間密室，將重要的資源放到密室中。而密室是對外不開 放的，也就說密室中的資源必須通過tomcat服務器的內部轉發(fā)才能進行訪問。就 算瀏覽器聽說項目有這樣密室，并且密室中也有瀏覽器想要的資源，瀏覽器發(fā)起的 請求地址是正確的，但是我們可以在服務器端死不承認，我們沒有這個資源，在后 臺給瀏覽器響應404.如果是我們覺得靠譜的請求，我們就在服務器端請求轉發(fā)資 源給瀏覽器使用。

項目密室:

其實我們的web項目在創(chuàng)建的時候就自動的在web目錄下創(chuàng)建了密室，就是
WEB-INF文件夾。也就是說WEB-INF文件夾下的資源瀏覽器是無法直接訪問
的，必須通過內部請求轉發(fā)才能訪問。

代碼示例:

[2] 使用自定義視圖解析器優(yōu)化資源跳轉路徑

問題:

我們在將重要的項目資源放在WEB-INF文件夾中后，只能通過內部的請求轉發(fā)來
訪問資源。如果WEB-INF下的資源較多，造成請求轉發(fā)的路徑書寫麻煩，而且后 期一旦資源的目錄發(fā)生變更，修改起來會非常的麻煩，怎么辦?

解決:

我們真正想在單元方法中想寫的是資源的名字，而請求轉發(fā)WEB-INF下的資源路 徑是公共的，每次都要寫。而剛好我們的自定義視圖解析器就是專門用來進行請求
轉發(fā)的，而且可以設置轉發(fā)資源的公共前綴和后綴信息。所以，我們可以使用自定 義視圖解析器來完成WEB-INF下的資源的請求轉發(fā)。

示例：
SpringMVC.xm中配置自定義視圖解析器

聲明單元方法請求轉發(fā)，注意：返回值直接為資源名

[3] 使用restful聲明公共單元方法請求轉發(fā)WEB-INF下的資源

問題:

在項目中使用了自定義視圖解析器后，可以在單元方法中簡單的返回一個 WEB-INF下的資源的名字就可以完成資源的請求轉發(fā)了，美滋滋。但是我們的資 源是非常多的，但是我們的單元方法的返回值只能有一個。總不能我們給WEB-INF
下的每個資源都聲明一個對應的單元方法來完成請求轉發(fā)吧，太麻煩了。

解決:

根據(jù)請求，請求轉發(fā)WEB-INF下的資源的單元方法是肯定要聲明的。我們可以
聲明一個公共的單元方法，該單元方法不參與請求的邏輯處理，只負責根據(jù)請求
轉發(fā)WEB-INF下的資源。

實現(xiàn)：

使用restful完成

示例:

[4] 重新配置springmvc.xml文件中的資源放行

總結

以上是生活随笔為你收集整理的SpringMVC的视图解析器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。