(目錄)

1. 什麼是 Spring MVC？

官方描述：https://docs.spring.io/springframework/docs/current/reference/html/web.html#spring-web

Spring Web MVC is the original web framework built on the Servlet API and has been included in the Spring Framework from the very beginning. The formal name, “Spring Web MVC, ” comes from the name of its source module ( spring-webmvc), but it is more commonly known as “Spring MVC” .

翻譯成中文：

Spring Web MVC 是基于 Servlet API 建構的原始 Web 架構 ，從⼀開始就 包含在 Spring 架構中 。它的正式名稱“Spring Web MVC”來⾃其源子產品的名稱(Spring-webmvc)，但它通常被稱為“SpringMVC”.

從上述定義我們可以得出兩個關鍵資訊：

Spring MVC 是⼀個 Web 架構 。（基于 Servlet 實作的）

web架構，就是基于 HTTP 協定的。

通俗來說：當使用者在浏覽器上輸入一個 URL 位址之後，URL 位址能夠和程式映射起來。

能夠讓使用者的請求被程式接受到。

并且，經過程式的處理，能把結果傳回給前端（浏覽器）。

這一次基于 HTTP 的互動，就可以認為是一個 web 項目。

Spring MVC 也是一個 web 架構（spring 的一個 web 子產品）。

那麼，一個 web 項目，隻做三件事:

1、實作使用者請求到程式的連結。（使用者請求可以被程式接收到，也就是上面講的）

2、在前後端建立聯系的情況下，拿到使用者請求的參數。

3、拿到參數之後，進行業務處理，并将其結果傳回給前端。

如果有看過我前面部落格的讀者，回想一下：我在将 spring 的時候，并沒有涉及前端。

隻有在講解 Spring Boot 的時候，涉及到 web内容。

我們不是引入了一個 spring web 嘛，那個就是前端架構。

有了這個架構的支援，那麼，項目就是一個 Spring MVC 的項目。

也就是說：其實前面建立的 Spring Boot 項目是一個 Spring MVC 項目。

Spring MVC 是基于 Servlet API 建構的 。

1.1 什麼是 MVC?

Model View Controller(模型,視圖,控制器) ,他是一種 設計模式
。

這種設計模式将軟體(項目)分為三部分:
模型,視圖,控制器

【Spring boot】MVC 與 SpringMVC，擷取請求參數（Cookie、Session、Header）、請求轉發、請求重定向1. 什麼是 Spring MVC？2. Spring MVC 項目建立請求轉發或請求重定向

Model（模型）
是應用程式中用于處理應用程式資料邏輯的部分。通常模型對象負責在資料庫中存取資料。

View（視圖）
是應用程式中處理資料顯示的部分，通常視圖是依據模型資料建立的。

Controller（控制器） 是應⽤程式中處理⽤戶互動的部分。通常控制器負責從視圖讀取資料，控制⽤戶輸⼊，并向模型發送資料。

下面我們來進一步分析四者之間的關系：

1.2 MVC 和 SpringMVC 什麼關系?

MVC 是一種

設計思想

,而 SpringMVC 是一個

具體的實作

架構.

SpringMVC 是一個基于 MVC 設計模式和 Servlet API 實作的 Web 架構,同時 SpringMVC 又是 Spring 架構中的一個 WEB 子產品,他是随着 Spring 的誕生而存在的一個架構.

Spring 和 SpringMVC 誕生曆史比較久遠,在他們之後才有了 Spring boot.

1.3 為什麼要學 Spring MVC？

現在

絕大部分的 Java 項目都是基于 Spring（或 Spring Boot）

的，而

Spring 的核心就是 Spring MVC

。

也就是說

Spring MVC 是 Spring 架構的核心子產品

，而

Spring Boot 是 Spring 的“腳手架”，

是以我們可以推斷出，現在市面上絕大部分的 Java 項目都是 Spring MVC 項目，這是我們要學 Spring MVC 的原因。

現在的項目，有兩種：

1、 PC
，電腦上運作的項目

2、
移動端 ，手機上的運作的項目。

PC 項目，又可以分為2種：

1、網頁版項目，

2、用戶端的項目

但是不管你 PC 項目屬于哪一種，隻要你需要 資料持久化 ，就是 用到 Spring MVC
。

而那種小工具（對本地檔案進行查找和管理的工具），是用不到資料庫的，它肯定是不會使用到 Java 程式。這種小項目（個人項目 / 小工具），我們大機率是不從事這方面的開發。

因為能要你的公司，它肯定是能賺到錢的。

賺不到錢，人家招你幹嘛？賠錢嘛。。。

工作之後，不管是做哪一種 PC 開發，都是
要連接配接資料庫
的。

隻要是用到了資料庫的，那
一定是前後端分離
的。

是以說：我們提供的就是
後端程式
。

那後端程式是基于什麼協定呢？》》》 HTTP協定

是以說，
HTTP協定
需要使用什麼架構？

一定
web（Spring MVC）架構
嘛！

手機項目也是一樣，拿着手機去刷抖音，看頭條……

這些内容都是來自于資料庫的。

資料庫，這個東西實在我們手機上存的嗎？很顯然，不現實！

資料庫，這東西一定是存儲在伺服器端的。

而
伺服器端是誰提供的
？

是手機開發工程師，他自己做後端開發嗎？

肯定不做啊！手機開發工程師做的是 PC時代的前端（做網頁的）。

很早以前，PC 的前端是做網頁的。

現在，PC 的前端是做 APP的，就是說現在的網頁，已經不是一個簡簡單單 HTML 頁面，而是可以視為是一個 APP，具有很多複雜的功能。

但是，
後端一定是調用服務接口 ，而服務接口大部分調用額是 HTTP協定。HTTP 協定就需要用到 Spring MVC 架構，因為它 底層 就是針對 Servlet
封裝的。

是以它一定是一個 web 項目。

由此可知，我們到公司之後，大部分項目，大約 99% 都是 Spring MVC 項目。

拓展說一下：

APP 項目 也可以分為兩種：

基于 iOS 開發
，最早使用 ObjectC，但是寫法極其惡心。

是以，蘋果公司，在後面又推出了自己的語言
Swift 。

安卓開發 ，最早是基于 Java 開發，但是現在谷歌被 Oracle 給搞了。

是以，自己和 idea 的公司合作，做了一門新語言 Dart
。

但是！底層也還是基于 JVM 的。

與 java 編譯生成的位元組碼檔案，可以視為是一樣的。

而且，Dart 與 Java 是非常相似的！

可以說：這門語言就是為了堵住 Oracle 的 “嘴”。

但是呢，現在APP發展的趨勢，趨近
兩者的混合開發
。

就是蘋果和安卓手機，都能安裝這個 APP。

關于混合開發，已經是陳年舊事了。

最早推出的是 Facebook 的
React Native
。

也是屬于
門面模式
的一種實作。

你可以寫 React Native 自己的文法，在項目打包的時候，它有一個選擇平台的功能。

根據我們寫的代碼，去生成 IOS 的代碼，或者是安卓的代碼。

不同的平台，我給你生成不同的代碼，就行了。

2. Spring MVC 項目建立

我們隻要基于 Spring Boot 架構添加一個 Spring Web(它使用的就是 Spring MVC)依賴,此時的項目就變成了Spring MVC項目.

簡單來說，咱們之是以要學習 Spring MVC 是因為它是⼀切項⽬的基礎，我們以後建立的所有 Spring、Spring Boot 項⽬基本都是基于 Spring MVC 的。

2.1 使用使用者和程式的映射

2.1.1 方法一: 使用@RequestMapping(“/xxx”)

創一個

UserController

類,實作使用者到 Spring 程式的互聯互通:

import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.ResponseBody;

@Controller
@ResponseBody // 表示的是傳回一個非靜态頁面的資料
@RequestMapping("/user") //類上面的 RequestMapping 可以省略
public class UserController {

    @RequestMapping("/sayhi")
    public String sayHi(){
        return "Hello World!";
    }
}

@ResponseBody注解

1、放在 方法
上，表示該方法傳回的資料，隻是一個普通的資料，而非一個靜态頁面。

2、放在
類
上，表示該類中所有的方法傳回的資料，都是一個普通的資料，而非靜态頁面。

3、如果
未加 上這個注解，在我們通路方法的時候，預設就會去尋找一個名稱叫做 Hello World！的頁面，它發現找不到之後，就會報錯。

@RequestMapping 特征:

既能修飾類(可選)也能修飾方法

預設情況下,既支援 POST 請求方式,也支援 GET 請求方式

@RequestMapping

參數擴充(隻支援某種類型的請求方式,

比如 POST 類型的請求方式

@RequestMapping(method = RequestMethod.POST,value = "/sayhi")

隻支援 GET：

@RequestMapping(method = RequestMethod.GET,value = "/sayhi")

2.1.2 方法二: 使用@PostMapping(“/xxx”)

隻支援 POST 請求方式

@PostMapping("/sayhi2")

2.1.3 方法三: 使用 @GetMapping(“/xxx”)

隻支援 GET 請求方式

@GetMapping("/sayhi3")

小總結:

@RequestMapping 既支援 GET 也支援 POST,但他也可以設定指定 GET 或 POST @GetMapping 隻支援 GET 請求, PostMapping 隻支援 POST 請求

2.2 擷取使用者請求參數

2.2.1 擷取單個參數

在 Spring MVC 中可以直接⽤⽅法中的參數來實作傳參.

在傳遞單個參數的時候，最常傳遞的參數是 id。

上述這種方式，隻要擷取的參數名稱，與前端傳輸的參數名稱一緻，就能擷取到對應的參數值。

如果 前端參數名稱和映射方法的參數名稱，不一樣
。

不但
擷取不到，還會報錯 ！

2.2.2 擷取多個參數 / 表單參數傳遞（非對象）

我們簡單實作回顯服務。

傳遞什麼參數，就傳回什麼參數。

方法還是一樣的，隻要前端傳遞的參數名稱和後端映射方法參數名稱相同，就能夠擷取一個，甚至多個參數。

但是目前這個代碼存在很大的問題，就是參數一旦增加。

我們就得手動去添加，還可能漏掉某個參數，

而且，維護的時候，也很難看清楚代碼，
參數太多了！維護性極低
。

那麼，我們該怎麼去處理呢？

接着往下看！

2.2.3 擷取對象

擷取對象，那就很簡單了！！！

映射方法隻需要一個對象參數就行了。

擷取對象參數的重點，還是在前端傳參的時候，參數名稱要與對象中的屬性名稱相對應，Spring MVC 就會自動對對象的屬性進行指派。

如果名稱不比對，那麼，這個參數傳輸的毫無意義。

2.2.4 參數重命名( @RequesParam 注解 )

某些特殊的情況下， 前端傳遞的參數 key 和我們後端接收的 key 可以不⼀緻
。

⽐如前端傳遞了⼀個name 給後端，⽽後端⼜是有 username 字段來接收的，這樣就會出現參數接收不到的情況，如果出現這種情況，我們就可以使⽤
@RequestParam 來重命名前後端的參數值 .

這裡有一個細節：

如果這個重命名操作的屬性， 對象裡面的，就不能這麼去用 ！！！

上面的那個 username ，并不是 UserInfo 中的屬性，隻是一個普通的字元串變量名.

我都沒将 UserInfo 類注入到Spring 中，更别提擷取到類中的屬性。

使用 @RequestParam 注解注意事項：

如果在參數中添加 @RequestParam 注解,那麼前端一定要傳遞此參數,否則就會報錯,如果想要解決此問題,可以給 @RequestParam 裡面添加 required = false ， 參數是否必須傳遞

2.2.5 擷取 JSON 格式的資料(@RequestBody)

要使用

@RequestBody

這個注解:

通過擷取普通對象的方法，來擷取一個 json 格式的對象參數。顯然是不行的！

由此，不難得出結論:

隻要不是 json 格式的資料，無論是 GET 還是 POST 方法的請求，都沒有問題！

這一點在前面的例子中，就已經充分展現出來了。

也就是說：想

要通過接收 json 對象

，需要通過其它的方法來實作。

當然還是注解，這個注解就是

@ RequestBody 注解

2.2.6 從 URL 位址中擷取參數 (@PathVariable)

這個就厲害了，它不滿足于從請求的正文和 URL 中的查詢字元串中擷取參數了。

而是

從 URL 中擷取參數

。

注意！我的描述： @PathVariable注解
，不滿足從請求的正文和 URL 中的查詢字元串（參數部分），擷取參數。

而是直接從 URL位址中擷取參數。

【Spring boot】MVC 與 SpringMVC，擷取請求參數（Cookie、Session、Header）、請求轉發、請求重定向1. 什麼是 Spring MVC？2. Spring MVC 項目建立請求轉發或請求重定向

2.2.7 上傳檔案( @RequestPart )

現在不是之前那種簡單資料了，它可能是一個資料流。

它傳過來的是一個 “流”。

比如：

我們在進行使用者注冊的時候，要上傳一個頭像（圖檔）。

也就是說：上傳的資料，就是這個
圖檔的位元組流
。

類似于這種上傳檔案的形式，我應該怎麼去擷取呢？

通過
@RequestPart 注解，并将檔案名稱作為參數放入其中，同時還需要 借助 Spring 提供 MultipartFile對象
。

MultipartFile，就是專門用來接收檔案的。

拓展：優化存儲目錄

首先，我們先來補充關于日志檔案的知識補充。

這樣做的好處：

哪怕配置檔案再多，我們也就隻需要修改主配置檔案中的一個參數，就可以調用對應的配置檔案了。

總結：

1、針對各個平台，建立專屬的配置檔案

2、配置檔案的命名規則：application + 分隔符“ - ” + 平台名稱（可簡寫） + .格式【必須這麼去寫】

3、在主配置檔案中設定運作的配置檔案。【spring.profiles.active】

圖檔名稱不能重複 && 擷取原圖格式問題

先把主配置檔案中的參數改成 develop （開發環境）

要不然識别不了，畢竟我們現在是在本地操作。

我們先來

解決 圖檔名稱 問題

。

第一種：

時間戳

通過時間戳來命名圖檔，是存在問題的。

其實 “巧合”，在網際網路中是很常見的。

是以，很有可能就有那麼幾個人，同時，上傳圖檔。

還是會造成圖檔名稱的重複，導緻原先的圖檔被覆寫。

隻是發生的機率要小一些。

是以，不可取的。

因為它不适合用于并發執行的情況。

第二種：

UUID

（全局唯一辨別符）

UUID就不會從出現時間戳的情況。

UUID 會使用你的網卡，随機數，等等，，，各種各樣的資訊來對檔案進行命名。

在這種條件下，命名重複的機率，幾乎不可能出現。

現在存儲路徑的問題搞定了，

圖檔名稱重複的問題

搞定了。

就剩下擷取原上傳圖檔的格式了。

其實 MultipartFile 對象中，提供了一個 API （ getOriginalFilename ）。 getOriginalFilename：擷取原始的檔案名稱 名稱裡面都有什麼？有檔案字尾啊！ 想辦法截取檔案字尾 ，不就可以了嘛。

問題都有了解決方案，接下來就是實施環節。

2.2.8 擷取 Cookie

① 基于servlet 擷取 Cookie 的方法

@RequestMapping("/cookie")
    public void getCookie(HttpServletRequest request) {
        // 得到全部的 Cookie
        Cookie[] cookies = request.getCookies();
        for (Cookie item : cookies) {
            log.info("Cookie Name：" + item.getName() +
                    " | Cookie Value：" + item.getValue());
        }
    }

這樣的缺點：就是

一次都把所有的 cookie 都給讀出來了

② 使用 @CookieValue 注解實作 Cookie 的讀取

@RequestMapping("/cookie2")
    public String getCookie2(@CookieValue("456") String cookie) {
        return "Cookie Value：" + cookie;
    }

2.2.9 擷取 Header (請求頭) 裡面的資訊

① Servlet 方式

@RequestMapping("/getua")
    public String getHead(HttpServletRequest request) {
        return "header：" + request.getHeader("User-Agent");
    }

② 使用注解 @RequestHeader 的方式

@RequestMapping("/getua2")
    public String getHead2(@RequestHeader("User-Agent") String userAgent) {
        return "header：" + userAgent;
    }

2.2.10 存儲 Session

@RequestMapping("/setsess")
    public boolean setSession(HttpServletRequest request) {
        boolean result = false;
        // 1.得到 HttpSession
        HttpSession session = request.getSession(true); // true=如果沒有會話，那麼建立一個會話
        // 2.使用 setAtt 設定值
        session.setAttribute("userinfo", "張三");
        result = true;
        return result;
    }

設定(存儲)Session 之前：

存儲 Session 之後:

儲存了SessionId 就傳給伺服器擷取

2.2.11 擷取 Session

① Servlet 方式

@RequestMapping("/getsess")
    public String getSession(HttpServletRequest request) {
        String result = null;
        // 1.得到 HttpSession 對象
        HttpSession session = request.getSession(false); // false=如果有會話，使用會話，如果沒有，那麼不會新建立會話
        // 2.getAtt 得到 Session 資訊
        if (session != null && session.getAttribute("userinfo") != null) {
            result = (String) session.getAttribute("userinfo");
        }
        return "會話: "+result;
    }

先存才取:

② 使用注解 @SessionAttribute 的方式

@RequestMapping("/getsess2")
    public String getSession2(@SessionAttribute(value = "userinfo",
            required = false) String userinfo) {
        return "會話：" + userinfo;
    }

請求轉發或請求重定向

forward VS redirect

return 不但可以傳回⼀個視圖，還可以實作跳轉，跳轉的⽅式有兩種：

1、 forward 是 請求轉發
；

2、
redirect ：是 請求重定向 。

forward 請求轉發實作

當我們通路到 myForward 方法，執行到return 語句的時候。

請求轉發

，是

伺服器端的一個行為

。

伺服器端會通路這個頁面，并且将頁面的資料傳回給用戶端。

這個就好比，我們在大學時期，我們想吃飯的時候，叫室友爸爸帶飯一樣。

此時，我們就相當于是用戶端，室友爸爸就是伺服器。

食堂的飯菜，就是想要的網頁資料。

當我們向室友爸爸提出帶飯請求，室友爸爸接收到請求之後，他就會去通路食堂大媽。

擷取大媽手中的飯菜，将其帶回給我們。

簡單來說：

伺服器端（室友）就是一個中間商，用戶端（我們）想要擷取的資料（飯菜），并非來自伺服器端自身。

隻是說：不用我們（用戶端）去打飯（擷取資料），他（伺服器端）會幫我們找到它，将它帶回來給我們。

由張圖我們可以看出，對于目标服務的資料，是共享的。

無論是誰通路，都可以通路該頁面的資料。

redirect：請求重定向實作

通過上述操作，展示出來的效果。其實就已經展現出轉發與重定向的差別了。

轉發，它的URL 是不會改變的；

重定向，URL位址變成了通路頁面的位址

這是其一。

其二：

轉發，浏覽器隻需要發送一條請求，就能擷取到網頁資訊。

重定向，浏覽器需要發送兩條請求，才能擷取網頁資訊。

還是舉那個例子：

我們代表用戶端，室友弟弟代表伺服器端，飯菜就是網頁資料。

此時，我們像往常一樣，向室友爸爸發送一個帶飯請求。

但是！他這個弟弟居然居然拒絕了，而且說是要去約會！！！

告訴我們，隻能自己去食堂買飯了。（這就是第一個請求，傳回的302響應）

那我們還能怎麼辦，當然弟弟的幸福重要。。。

于是我們隻能自己去買飯了。（這就對應着第二個請求）

簡單來說：

重定向，是前端的一種行為。

直白來說：前端向後端索要資料，後端隻告訴了它去哪裡拿，前端需要自己去擷取。

需要注意的是：

重定向，資料是不共享的。

就是我給你的位址，你能不能通路到資料，是不确定的。

萬一，這份資料是需要權限的，但是你沒有，那就通路不了了。

或者這網站，被登出了，你也是通路不了的！

差別總結

forward 和 redirect 具體差別如下：

1、請求重定向（redirect）将請求重新定位到資源；請求轉發（forward）伺服器端轉發。

直白來說：定義不同。

請求轉發（Forward）：發生在服務端程式内部，當伺服器端收到一個用戶端的請求之後，會先将請求，轉發給目标位址，再将目标位址傳回的結果轉發給用戶端。

重定向：甩給你目标位址，其它事情與我無關。

2、請求重定向位址發⽣變化，請求轉發位址不發⽣變化。

3、重定向浏覽器會發送兩條請求，轉發，隻有一條請求。

4、重定向，資料不共享；轉發，資料共享。

5、請求重定向與直接通路新位址效果一緻，不存在原來的外部資源不能通路；請求轉發伺服器端轉發有可能造成原外部資源不能通路。

請求轉發 forward 導緻的問題:

請求轉發如果資源和轉發的⻚⾯不在⼀個⽬錄下，會導緻外部資源不可通路。

我們寫的這種，是相對路徑。

如果通路的資源，分級（分包）存儲。

此時，就需要根據目前路徑做出改變。

保險的做法就是寫絕對路徑。

當然，相對路徑寫起來要簡單一些。

看個人選擇。

重定向，是直接給你目标通路的位址，它本身的位址并沒有被改變。

而轉發，假設我們實作請求轉發的方法，是處于一級路徑，通路的源在二級目錄。

是以，它的位址發生了改變，從二級目錄變成一級目錄，

那麼，一級目錄中的相對資源就會丢失了。

這就是請求轉發存在的一個問題。

【Spring boot】MVC 與 SpringMVC，擷取請求參數（Cookie、Session、Header）、請求轉發、請求重定向1. 什麼是 Spring MVC？2. Spring MVC 項目建立請求轉發或請求重定向

1. 什麼是 Spring MVC？

1.1 什麼是 MVC?

1.2 MVC 和 SpringMVC 什麼關系?

1.3 為什麼要學 Spring MVC？

2. Spring MVC 項目建立

2.1 使用使用者和程式的映射

2.1.1 方法一: 使用@RequestMapping(“/xxx”)

2.1.2 方法二: 使用@PostMapping(“/xxx”)

2.1.3 方法三: 使用 @GetMapping(“/xxx”)

2.2 擷取使用者請求參數

2.2.1 擷取單個參數

2.2.2 擷取多個參數 / 表單參數傳遞（非對象）

2.2.3 擷取對象

2.2.4 參數重命名( @RequesParam 注解 )

2.2.5 擷取 JSON 格式的資料(@RequestBody)

2.2.6 從 URL 位址中擷取參數 (@PathVariable)

2.2.7 上傳檔案( @RequestPart )

拓展：優化存儲目錄

圖檔名稱不能重複 && 擷取原圖格式 問題

2.2.8 擷取 Cookie

① 基于servlet 擷取 Cookie 的方法

② 使用 @CookieValue 注解實作 Cookie 的讀取

2.2.9 擷取 Header (請求頭) 裡面的資訊

① Servlet 方式

② 使用注解 @RequestHeader 的方式

2.2.10 存儲 Session

2.2.11 擷取 Session

① Servlet 方式

② 使用注解 @SessionAttribute 的方式

請求轉發或請求重定向

forward VS redirect

forward 請求轉發 實作

redirect：請求重定向 實作

差別總結

繼續閱讀

圖檔名稱不能重複 && 擷取原圖格式問題

forward 請求轉發實作

redirect：請求重定向實作