目錄

什么是 Spring MVC？

MVC 定義

MVC 和 Spring MVC 的關系

為什么要學 Spring MVC？

Spring MVC 項目的創(chuàng)建

學習 Spring MVC 的 三個目標

Spring MVC項目的連接(用戶 和 程序 的 映射)

方法1：@RequestMapping(“/xx”)

@RequestMapping 是 post 還是 get 請求？

總結 && 拓展

?方法2 和 方法 3：@GetMapping??和 PostMapping

獲取用戶請求參數

傳遞單個參數

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

獲取多個參數 / 獲取對象

拓展

后端參數重命名（后端參數映射：@RequestParam?）

?@RequestParam 的進一步理解: required屬性

表單參數傳遞（對象）

?@RequestBody 接收JSON對象 - 特殊

?獲取URL中參數@PathVariable - 特殊

上傳文件 - @RequestPart

?圖片名稱不能重復 && 獲取原圖格式 問題

獲取Cookie/Session/header

知識鋪墊：獲取 Request 和 Response 對象

獲取 Cookie

?獲取 header（獲取請求頭中的信息）

存儲 和 獲取 Session

返回數據給前端

練習

實現計算器功能 - form 表單

拓展： Spring MVC 的 熱部署 設置

1.添加熱部署框架?持

2、Settings 開啟項??動編譯

3.開啟運?中熱部署

效果展示?編輯

模擬登錄功能，前端使? ajax，后端返回 json 給前端。

前端代碼

后端代碼

效果圖

小拓展：前端返回一個json數據，后端可以接收。

請求轉發(fā)或請求重定向 - 重點

forward VS redirect

forward 請求轉發(fā) 實現?編輯

redirect：請求重定向 實現

區(qū)別總結

什么是 Spring MVC？

官?對于 Spring MVC 的描述是這樣的：

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)，但它通常被稱為“Spring MVC”。?

題外話：
1、因為 Spring Web MVC 是基于 Servlet API，所以 Servlet 是 Spring MVC 的 “父親”。
因此，Servlet 那一套編程方法，在 Spring MVC 中，也是可以使用的?。?！
但是，一般不推薦使用 servlet 的編程方式。
因為，Spring MVC 更簡單！
?
2、Spring Web MVC，從?開始就包含在 Spring 框架中。
即：Spring 是一個很大體系（框架），Spring MVC 只是屬于 Spring 體系中的一個 Web 模塊。
這也是為什么在學習 Spring 的時候，我們都都是通過 main 方法去訪問bean方法的原因。因為我們沒有引入 web 模塊，因此想要通過 瀏覽器輸入 URL 來訪問 方法，是不行的。?

從上述定義我們可以得出兩個關鍵信息：
1、 Spring MVC 是?個 Web 框架。（基于 Servlet 實現的）

web框架，就是基于 HTTP 協議的。
通俗來說：當用戶在瀏覽器上輸入一個 URL 地址之后，URL 地址 能夠和 程序映射起來。
能夠讓用戶的請求 被 程序接受到。
并且，經過程序的處理，能把結果返回給前端（瀏覽器）。
這一次基于 HTTP 的交互，就可以認為是一個 web 項目。

Spring MVC 也是一個 web 框架（spring 的 一個 web 模塊）。
那么，一個 web 項目，只做三件事:
1、實現用戶請求 到 程序 的 鏈接。（用戶請求 可以 被 程序接收到，也就是上面講的）
2、在前后端建立聯系的情況下，拿到用戶請求的參數。
3、拿到參數之后，進行業(yè)務處理，并將其結果返回給前端。

這也是 本文講解 Spring MVC 的重點。
?
如果有看過我前面博客的讀者，回想一下：我在講?spring 的時候，并沒有涉及 前端。
只有在講解 Spring Boot 的時候，涉及到 web內容。
我們不是引入了一個 spring web 嘛，那個就是 前端框架。
有了這個 框架的支持，那么，項目就是一個 Spring MVC 的項目。
也就是說：其實前面創(chuàng)建的 Spring Boot 項目 是 一個 Spring MVC 項目。

?
2、 Spring MVC 是基于 Servlet API 構建的。
然?要真正的理解什么是 Spring MVC？我們?先要搞清楚什么是 MVC？?

MVC 定義

????????MVC 是 Model View Controller （模型視圖控制器）的縮寫，它是軟件?程中的?種軟件架構模式，它把軟件系統分為模型、視圖和控制器三個基本部分。

Model（模型） 是應用程序中用于處理應用程序數據邏輯的部分。通常模型對象負責在數據庫中存取數據。
?
View（視圖） 是應用程序中處理數據顯示的部分，通常視圖是依據模型數據創(chuàng)建的。
?
Controller（控制器） 是應?程序中處理?戶交互的部分。通?？刂破髫撠煆囊晥D讀取數據，控制?戶輸?，并向模型發(fā)送數據。
?
下面我們來進一步分析 四者之間的關系。?

通過這個 MVC 模型，就可以讓 用戶 與 程序 之間，是可以進行完美的交互的 。

間接來說：（忽略細節(jié)）

1. 前端發(fā)送的請求數據，會先給 controller。
2. controller 驗證完數據之后，就會將其給 Model。
3. Model 在和 數據庫交互之后，將其得到的結果返回給 controller。
4. 此時 controller 收到的數據，還不能直接返回給前端。
5. controller 需要將數據 交給 服務器的視圖（View），進行處理和渲染。
6. 最終，將渲染得到的結果，返回給前端。

此時，用戶就看到的源碼 就是 html標簽 的內容。（瀏覽器的開發(fā)者工具可以查看）
看到的頁面，就是瀏覽器對 HTML標簽內容的解析。

此時，我們基于 MVC 這三個部分，就可以實現一個 web 項目了。

web 項目：用戶通過瀏覽器輸入一個 URL，發(fā)送一個 HTTP請求，能夠與 服務器 進行一次交互 和 響應。?

MVC 和 Spring MVC 的關系

IOC 是思想，DI 是具體實現。
MVC 和 Spring MVC 的關系，也是如此。
MVC 是一種?設計思想（策略）。
Spring MVC 是?具體實現的框架。

總結
????????Spring MVC 是?個實現了 MVC 模式，并繼承了 Servlet API 的 Web 框架。既然是 Web 框架，那么當?戶在瀏覽器中輸?了 url 之后，我們的 Spring MVC 項 ?就可以感知到?戶的請求。
?
????????同時 Spring MVC 又是 Spring 框架中的 一個 WEB 模塊，它是隨著 Spring 的 誕生 而 存在的一個框架。

Spring 和 Spring MVC 誕生的歷史是比較久遠的，在它們之后才有了 Spring Boot。
Spring 大概是在 2002 年 上市的，而 Spring Boot，大概比 Spring 晚 十年 誕生的。
Spring Boot 是在 2.0 版本的時候，占據了中國市場。?

為什么要學 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。

工作之后，不管是 做 哪一種 PC 開發(fā)，都是要連接數據庫的。
只要是用到了 數據庫的，那一定是前后端分離的。
所以說：我們提供的就是 后端程序。
那后端程序是基于什么協議呢？->?HTTP協議
所以說，HTTP協議 需要使用什么框架？
一定 web（Spring MVC） 框架嘛！
?
手機項目也是一樣，拿著手機去刷抖音，看頭條。。。
這些內容都是來自于數據庫的。
數據庫，這個東西實在我們手機上存的嗎？很顯然，不現實！
數據庫，這東西一定是存儲在服務器端的。
而服務器端是誰提供的？
是 手機開發(fā)工程師，他自己做后端開發(fā)嗎？
肯定不做?。∈謾C開發(fā)工程師 做的是 PC時代的前端（做網頁的）。
很早以前，PC 的前端是做網頁的。
現在，PC 的前端是 做 APP的，就是說現在的網頁，已經不是一個簡簡單單 HTML 頁面，而是可以視為是一個 APP，具有很多復雜的功能。
但是，后端一定是調用 服務接口，而 服務接口 大部分調用額是 HTTP協議。HTTP 協議 就需要用到 Spring MVC 框架，因為它底層就是針對 Servlet 封裝的。
因此 它 一定是一個 web 項目。
?
由此可知，我們到公司之后，大部分項目，大約 99% 都是 Spring MVC 項目。
那么，你覺得 Spring MVC 重不重要呢？ 非常重要?。。?！
?
這里簡潔的說一下：APP 項目也可以分為兩種。
1、基于 iOS 開發(fā)，最早使用 ObjectC，但是寫法極其惡心。
所以，蘋果公司，在后面又推出了 自己的語言 Swift。
?
2、安卓開發(fā)，最早是基于 Java 開發(fā)，但是現在 谷歌 被 Oracle 給搞了。
所以，自己 和 idea 的公司合作，做了一門新語言 Dart。
但是！底層也還是 基于 JVM 的。
與 java 編譯生成的 字節(jié)碼文件，可以視為是一樣的。
而且，Dart 與 Java 是非常相似的！
可以說：這門語言就是為了 堵住 Oracle 的 “嘴”。
?
但是呢，現在APP發(fā)展的趨勢，趨近兩者的混合開發(fā)。
就是 蘋果 和 安卓 手機，都能安裝這個 APP。
關于 混合開發(fā)，已經是陳年舊事了。
最早推出的 是 Facebook 的 React Native。
也是屬于 門面模式的一種實現。
你可以寫 React Native 自己的語法，在項目打包的時候，它有一個選擇平臺的功能。
根據 我們寫的代碼，去生成 IOS 的 代碼，或者是安卓 的 代碼。
不同的平臺，我給你生成不同的代碼，就行了。
?
因此，移動端開發(fā)組 是很頭疼的，做一個 APP，需要分2組（IOS，安卓）。?

回過頭，我們在創(chuàng)建 Spring Boot 項?時，我們勾選的 Spring Web 框架其實就是 Spring MVC 框架，如下圖所示：?

從宏觀來說：
即使 Spring Boot 添加 Spring Web 框架，也可以說它是一個 Spring 項目，或者是 Spring Web 和 Spring MVC 項目，都可以！不算錯！
從微觀來說：
Spring MVC 項目，是基于 Spring Boot 框架 所實現的。

簡單來說，咱們之所以要學習 Spring MVC 是因為它是?切項?的基礎，我們以后創(chuàng)建的所有 Spring、Spring Boot 項?基本都是基于 Spring MVC 的。

Spring MVC 項目的創(chuàng)建

Spring MVC 項?創(chuàng)建和 Spring Boot 創(chuàng)建項?相同（Spring MVC 使? Spring Boot 的?式創(chuàng)建），在創(chuàng)建的時候選擇 Spring Web 就相當于創(chuàng)建了 Spring MVC 的項?

?刪除不常用文件。（可不刪，根據實際情況決定）

學習 Spring MVC 的 三個目標

學習 Spring MVC 我們只需要掌握以下 3 個功能：

1、 連接的功能：將?戶（瀏覽器）和 Java 程序連接起來，也就是訪問?個地址能夠調?到我們的Spring 程序。
2、 獲取參數的功能：?戶訪問的時候會帶?些參數，在程序中要想辦法獲取到參數。
3、輸出數據的功能：執(zhí)?了業(yè)務邏輯之后，要把程序執(zhí)?的結果返回給?戶。
對于 Spring MVC 來說，掌握了以上 3 個功能就相當于掌握了 Spring MVC?

Spring MVC項目的連接(用戶 和 程序 的 映射)

方法1：@RequestMapping(“/xx”)

在 Spring MVC 中使? @RequestMapping 來實現 URL 路由映射.

這個我在講 Spring Boot 知識的時候，已經用過了。
這里，我們再來穩(wěn)固一下。

注意： 一級路徑，通常是為了輔助 二級路徑。
因為一個項目，需要訪問的東西有很多。
不可能全寫在一個類里面，而且類也很多
為了避免混淆，所以通過這樣的方式，來鎖定要訪問的類中方法。

在這里，我再 給你們加強一下記憶。

@ResponseBody注解
1、放在方法上，表示該方法返回的數據，只是一個普通的數據，而非一個靜態(tài)頁面。
2、放在類上，表示該類中所有的方法返回的數據，都是一個普通的數據，而非靜態(tài)頁面。
3、如果未加上這個注解，在我們訪問方法的時候，默認就會去尋找一個名稱叫做 Hello World！的頁面，它發(fā)現找不到之后，就會報錯。

問題來了：為什么默認情況下，返回的是一個靜態(tài)頁面呢？

請思考一個問題：

這就原因所在，Spring MVC 在誕生之初，還沒有前后端分離的概念。
作為一個 Java 程序員，既要寫 后端代碼，還要去寫前端的頁面。
那個時候，模板用的非常多！！
那時候是沒有前后端工程師的，只要有一個 Java 工程師，就夠了。
最多，在配置一個美工（設計）就OK了。
所以，那個時候，不用多想，我肯定是返回的一個頁面。
為什么默認返回一個靜態(tài)頁面，就是一個歷史遺留問題。
到今天，格局全然不同！
前后端已經分離，再去返回一個靜態(tài)頁面，肯定是不行的，
但是！又不能舍棄 這個設置。
因為，前面開發(fā)的項目，你不能說 不要 就 不要?。。?br> 那都是錢砸出來的。
因此，保留這個機制，是為了以前的代碼還可以用。
而 添加 @ResponseBody，即實現了前后端分離。又能保存以前返回頁面的機制。
這樣就實現 項目 與 時代的兼容！

雖然不用返回界面了，但還是要寫兩個注解，稍微有點麻煩。

我們還要更簡單的寫法、是一個組合注解。
現在暫時放放，后面再講。
?
先繼續(xù)深入了解 @RequestMapping。

@RequestMapping 是 post 還是 get 請求？

@RequestMapping 默認是 get ?式的請求。
這一點其實在 瀏覽器通過 URL 訪問方法的時候，就已經證明了這一點。

通過 直接向瀏覽器的地址欄輸入URL，默認生成 get 請求。
不相信，可以使用postman 來驗證。

?那么，@RequestMapping 支持 POST 方法嗎？

答案：@RequestMapping，不僅支持 GET 方法，還支持 POST 方法的！

總結 && 拓展

?@RequestMapping 特征：
1、既能修飾類（可選），也能修飾方法。
2、默認情況下，@RequestMapping 既支持POST 方法，也支持 GET 請求方法。

但是問題來了：如果公司制定只能使用 POST 方法，不能使用 GET 方法。
這種公司是存在的，目的就是為了方便管理 。
?
像 @RequestMapping 這種 兩種都支持，就還好。
但是，有些接口只支持 一種 方法 的請求，可能是 POST，也可能是 GET，這都說不準。
主要看實際情況。
但是，這就會造成一個項目中，既有支持 get，又有支持post 的方法。
這就會導致一個問題：
每個人對代碼的理解是不一樣的。這就會增加程序員（前后端都包括）的負擔。
因為 在看每個接口在進行調用的時候，他要去看 說明文檔，然后，才能確定你當前這個接口是支持 GET，還是POST的 。
一些公司指定使用 一種 方法，就是為了避免這種情況。
程序不用去思考使用那種方法來寫代碼，直接按照公司的要求來。

那么，我的問題就是：能不能讓 @RequestMapping 只支持一種方法。

答案是可以的！
通過設置屬性值，就可以做到?。?！
這個屬性叫做 method

?需要注意的是：@RequestMapping 直接給路由參數，默認就是給 value 屬性賦值

還有一個細節(jié)：
類上的 RequestMapping 的路由參數，可以省略 / 的（雖然可以不加，但是還是建議加規(guī)范）

?方法2 和 方法 3：@GetMapping??和 PostMapping

你想的沒有錯，就是@RequestMapping 分解出來的 兩個注解。
意思很直白，你們應該是能懂的。
@GetMapping ：只支持 Get 方法

?@PostMapping：只支持 Post 方法。

獲取用戶請求參數

傳遞單個參數

在 Spring MVC 中可以直接??法中的參數來實現傳參.

在傳遞單個參數的時候，最常傳遞的參數是 id。
因為 id 通常是通過 primary key’（主鍵）來設置的，具有唯一性。
有助于我們獲取到唯一的數據。
這里我們不去訪問數據，直接通過訪問方法來演示一下就行，
主要是了解用法?

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

?如果 前端參數名稱 和 映射方法的參數名稱，不一樣。
不但獲取不到，還會報錯！

圖中說到 映射方法的參數類型，不能使用基本數據類型。
雖然正常情況下，代碼運行沒問題，和 使用 包裝類 的效果一樣。
但是像遇到上述這種特殊問題（前端傳輸參數名稱 和 映射方法名稱 不相符），代碼就會報錯。

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

?我們簡單實現 回顯服務。
傳遞什么參數，就返回什么參數。

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

?但是目前這個代碼存在很大的問題，就是參數一旦增加。
我們就得手動去添加，還可能漏掉某個參數，
而且，維護的時候，也很難看清楚代碼，參數太多了！維護性極低。
?
那么，我們該怎么去處理呢？
接著往下看！

獲取多個參數 / 獲取對象

獲取對象，那就很簡單了?。?！
映射方法 只需要 一個 對象參數 就行了。

獲取對象參數的重點，還是在 前端傳參的時候，參數名稱 要與 對象中的屬性名稱相對應，Spring MVC 就會自動 對 對象的屬性 進行賦值。
如果名稱不匹配，那么，這個參數傳輸的毫無意義。

拓展

后端參數重命名（后端參數映射：@RequestParam?）

跟給 Bean 對象重命名 是一樣的意思。
就是給 參數 改個名字。

某些特殊的情況下，前端傳遞的參數 key 和我們后端接收的 key 可以不?致！
?
?如前端傳遞了?個time 給后端，?后端?是由 createtime 字段來接收的，這樣就會出現參數接收不到的情況.
如果出現這種情況，我們就可以使? @RequestParam 來重命名前后端的參數值。

特殊情況，比如：
在將來的某一天，公司晚上突然加班，需要緊急添加一個需求。
更重要的是：產品明天就要上線了。
緊急加班嘛，代碼就寫的有點“粗”。
前后端，并沒溝通好。
假設，做的一個登錄功能的擴展
然后，產品是凌晨 2點上線的。
代碼也就沒有經過嚴格的測試。
因為 測試可能都下班，都是研發(fā)人員 去硬懟的。
?
第二天用的時候，運維發(fā)現了問題，通知 開發(fā) / 測試 人員，某某功能有問題。
比如：無論用戶怎么輸入，一直提示填寫用戶名。
?
最終，排查出的問題：
前端在傳輸參數的時候，參數名字 叫做 name，而后端參數是叫做 username。
這樣就會導致一直拿不到 用戶名的值。
這個時候，我們有兩種解決方案。
1、讓后端的代碼適應前端的代碼，修改映射方法的參數名稱（username >> name）。
但是一個問題也隨之而來。
就是啊，這個 username 已經在映射方法中，使用了很多次了。
這一改，方法中的代碼全都得動！
而且存在漏改的風險！
?
2、讓前端的代碼，適應后端的代碼。
讓前端傳回的參數 name >> username
這也會存在一個問題，像這種做完一個大項目的時候。
前端的人都休假，回到家直接關手機睡覺了。
但是這個bug 又很緊急！

總結：前端失聯，后端不想改。

這個時候，就可以使用 后端參數重命名了。

后端參數重命名，就是把前端傳過來的參數名稱，進行轉移賦值。
?
就是說：前端參數名稱不變，還是name；后端接收到之后，將其參數名稱的數值，賦值到 后端的 username 參數上。
此時，對于 后端來說，前端的 name，就是 username 了。
因為兩者的value 值，都是一樣的。

具體的實現方法，還是通過注解的方式來解決。
使用 @RequestParam 注解，就可以搞定了。

?雖然也有方法可以處理這種情況，但不是這個注解，是另一個。
（后面在 講 MyBatis 的時候，會說這個）
?
但如果映射方法的參數是一個對象，那就沒辦法了。
這個你就只能和前端交流了，讓他配合你的操作。
將 前端參數名稱 修改成 和 后端對象中的屬性名稱 一樣。
或者你配合他的代碼。。。。
將類中的屬性名修改成 和 前端參數一樣的名稱。

?@RequestParam 的進一步理解: required屬性

表單參數傳遞（對象）

表單傳遞對象參數，還是一樣的。
接受對象參數時，前端參數該怎么傳，就這么傳。

?上面是一個 get 方法的請求。
?
下面我們來通過 postman 構造一個 post 方法的 表單請求

?@RequestBody 接收JSON對象 - 特殊

有的人看到這個，感覺so easy！
既然 JSON 也是一個對象，這跟上面沒有區(qū)別嘛。
還是一樣的，前端直接傳輸一個 JSON 對象，映射方法這邊還是使用一個對象去接收。
下面，我就來驗證一下，程序能不能接收一個 JSON 對象的數據？

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

由此，不難得出結論:
只要不是 json 格式的數據，無論是 GET 還是 POST 方法的請求，都沒有問題！
這一點在前面的例子中，就已經充分體現出來了。

也就是說：想要通過接收 json 對象，需要通過其它的方法來實現。
當然還是注解，這個注解就是標題的 @ RequestBody 注解

PS：注意！不要迷糊了?。。。?br> 我們使用的 @RequestBody，不是 @ResponseBody。。。
@ResponseBody： 表示返回的數據是一個非靜態(tài)的頁面。
?
而 @RequestBody，是告訴 映射方法接下來接收到的數據是一個JSON 格式的數據。
方便對 JSON 數據，進行解析。

結論：
服務器端想要實現 json 數據的接收，就需要使用 @RequestBody 注解。

?獲取URL中參數@PathVariable - 特殊

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

注意！我的描述：
@PathVariable注解，不滿足從 請求的正文 和 URL 中的查詢字符串（參數部分），獲取 參數。
而是直接從 URL地址 中 獲取參數。

舉個例子：DOTA 都知道吧？一個推塔游戲。

比如，
我們現在想要獲取到一個 英雄的信息。

一般情況下，我們獲取英雄信息的方式，都是同 URL 的 查詢字符串部分來獲取的。
如：http://data2.uuu9.com?heroname=影魔
?
而通過 URL地址的方式來獲取英雄信息：http://data2.uuu9.com / 66 / 影魔 /
假設 66 是它的 ID。
那么，通過以往的方式去獲取這個英雄的信息，可以嗎？
很明顯，是不可以?。。?！
我們前面所學的方法，就沒有一個針對 URL地址部分的！

那么問題來了，為什么有正常的方式不用，用這種非主流的方式來獲取參數呢？

這個就涉及到 SU（搜索引擎） 的優(yōu)化。
什么是 SU 的優(yōu)化呢？

需要注意的是：
使用 第二種形式的URL，也是存在 " 缺點 " 的！?

不過 Spring MVC 又提供了一個新的注解 @PathVariable

其實也很好理解：path variable == 路徑變量。
?
隨之而來的是：路徑肯定是存在兩種形式的。
1、參數
2、路徑
那我們該如何區(qū)分 那個是參數，那個是路徑呢？
路徑的寫法不變，還是 “/xxx”
而參數的，就是在 / 后面，加上 大括號，將其后面的內容括起來： “/{xxx}”

?需要注意的一點：

上傳文件 - @RequestPart

現在不是之前那種簡單數據了，它可能是一個數據流。
它傳過來的是一個 “流”。

比如：
我們在進行用戶注冊的時候，要上傳一個頭像（圖片）。
也就是說：上傳的數據，就是這個圖片的字節(jié)流。
類似于這種上傳文件的形式，我應該怎么去獲取呢？
通過 @RequestPart 注解，并將 文件名稱 作為 參數放入其中，同時還需要借助 Spring 提供 MultipartFile對象。
MultipartFile，就是專門用來接收文件的。

還沒完，其實上述操作，還存在問題。

問題就出在 圖片 和 存儲路徑，都被寫死了。

?我們再來想象一個場景。

?所以，不能這么去寫！??！

拓展：不同平臺運行的配置文件設置 - 優(yōu)化存儲目錄

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

這樣做的好處：
哪怕配置文件再多，我們也就只需要修改 主配置文件中的一個參數，就可以調用對應的配置文件了 。

總結：
1、針對各個平臺，創(chuàng)建專屬的配置文件
2、配置文件的命名規(guī)則：application + 分隔符“ - ” + 平臺名稱（可簡寫） + .格式【必須這么去寫 】
3、在主配置文件中設置 運行的配置文件?！緎pring.profiles.active】

?圖片名稱不能重復 && 獲取原圖格式 問題

先把 主配置文件中 的 參數 改成 develop （開發(fā)環(huán)境）

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

下面，我們先來解決 圖片名稱 問題。
第一種：時間戳

通過 時間戳 來命名圖片，是存在問題的。
其實 “巧合”，在互聯網中是很常見的。
因此，很有可能就有那么幾個人，同時，上傳圖片。
還是會造成 圖片名稱 的重復，導致 原先的圖片被覆蓋。
只是發(fā)生的概率要小一些。
因此，不可取的。
因為 它不適合用于 并發(fā)執(zhí)行的情況。

第二種：UUID（全局唯一標識符）

UUID就不會從出現 時間戳的情況。
UUID 會使用 你的網卡，隨機數，等等，，，各種各樣的信息來對 文件 進行命名。
在這種條件下，命名重復的概率，幾乎不可能出現。

現在 存儲路徑的問題 搞定了，圖片名稱重復的問題 搞定了。
就剩下 獲取 原上傳圖片 的 格式 了。

其實 MultipartFile 對象中，提供了 一個 API（getOriginalFilename）。
getOriginalFilename：獲取原始的文件名稱
名稱里面都有什么？有文件后綴?。?br> 想辦法截取文件后綴，不就可以了嘛。

問題都有了解決方案，接下來就是實施環(huán)節(jié)。

注意！我們通過取巧的方式，來做的。
其實 uid 來也可以進行操作。

但是 局限性很強！
使用 uid 來 命名 圖片，只能使用一次。【唯一性】
但是！可能還有其它圖片，都是與用戶相關的。
當然，你可以通過添加前綴的方式來實現。
?
總的來說：還是更推薦使用 UUID 的方式，因為它更通用性更強。

獲取Cookie/Session/header

這三個是比較特殊，在有些場合，才會用到，
其中 獲取 Session 是比較常見的。

這三項，通常都不是（使用的一方）用戶 自動去上傳的。
都是由 前端工程師，或者是由系統給我們上傳的。
?
比如說：
Cookie，是瀏覽器自身去實現的。
它會在每一次請求中，都會把域名底下所有的 cookie 都帶上。
這都屬于 瀏覽器自身的行為。
當然，如果前端工程師愿意的話，他也可以 發(fā)送 cookie 給后端。
?
Session，也是一樣。
也是前端的瀏覽器自動發(fā)送給后端的。
但是后端是需要獲取到 Session 的。
畢竟，它用的比較多。
因為，用戶在登錄的時候，是需要通過 session 來驗證用戶信息的。
?
header，有些場景下，前端還會在 header 里面，設置自定義的header。
然后，傳遞到后端。
系統的header信息，有些時候，也是需要獲取的。
至于為什么要獲取 header，因為 header 里面有一個 userAge。
userAge 里面就記錄了當前訪問用戶的操作系統信息，以及他所使用的瀏覽器信息。
那我就可以每一次請求一個接口的時候，統計用戶 的 瀏覽器 和 操作系統 的信息。
在拿到 用戶 瀏覽器 和 操作系統的信息之后，方便對其進行分析。
根據 分析的結果，做一個排列，看看哪種瀏覽器的永輝最多，那個操作系統的用戶最多。
來進行針對性處理和優(yōu)化。
就是說：產品能夠更好的兼容這些比較熱門的操作系統 和 瀏覽器。

總之，一句話：我可以不用，但是不能不會！
至少我是知道有這么幾個東西的。

知識鋪墊：獲取 Request 和 Response 對象

因為 Spring MVC 就是 基于 Servlet API 來實現的。
也就是說：Servlet 那一套 是 完全適用于 Spring MVC 的。

在 Spring MVC 里面，每一個方法都有2個 “隱藏參數”、
【HttpServletRequest 和 HttpServletResponse】

?下面我們就來驗證一下功能。

?根據結果，更加證明了 Spring MVC 是 支持 Servlet API 的。

獲取 Cookie

獲取 Cookie 的方式有兩種：
1、基于 Servlet 提供 的 API 來獲取 Cookie

雖然，方法是可以的.。
但是這種讀取的方式，其實是有點“繁瑣的”！
因為需要先獲取 請求對象，通過對象提供的方法，來獲取 所有的cookie。
而 繁瑣，就體現在這一步！
通常情況，我們獲取 cookie 數據的時候，不會全拿，只拿取其中的一個。
?
由此，Spring MVC 提供一個新的注解，來往下看。

2、簡潔的獲取 Cookie - @CookieValue 這就很方便了！
想要那個 cookie 值，將其 cookieName 作為 @CookieValue 注解 的 參數，就能獲取到對應的value值。
當然，你還需要準備一個 “參數” 來接收。

?獲取 header（獲取請求頭中的信息）

?獲取 header 的 方法，也有兩種：
1、 基于 Servlet API

?2、簡潔獲取 Header—@RequestHeader

?相比于 Servlet API，注解的方式，還是更簡單一點的.

存儲 和 獲取 Session

為什么 Session 多出一個 存儲 的 操作呢？

原因很簡單！
就跟獲取 cookie 的 時候一樣！
你都沒有 session，我還獲取干什么？？
所以，才會多出這一步。

更特別的是：關于 存儲 操作，只能通過 servlet API。
因為存儲操作，是沒有辦法用參數來表示的。

讀取操作，是有兩種方法的。
1、servlet API

?2、更簡潔的獲取 session - 使用 注解 ：@SessionAttribute

至于為什么需要加上一個 required 屬性，并置為 false！
這因為 在使用 注解 獲取 session 對象的時候，沒有判斷句！
即：如果訪問 getSession2 方法的時候，沒有設置 session 會話，并且內置屬性。
此時，它就直接報錯！因為它找不到對應 key 值！
這是因為 @SessionAttribute 注解中，有required的屬性。
這個前面在講 @RequestParam 的時候，就講了。
不會像 servlet 那樣，返回一個 空值（頁面什么都不顯示）。
這個值，必須得有?。?！?

解決的方法，就是將 required 屬性，置為false。
表示這個 key 值，并不是非要找到！
而是找不到就算了！

返回數據給前端

通過上?的學習我們知道，默認請求下?論是 Spring MVC 或者是 Spring Boot 返回的是視圖（xxx.html），?現在都是前后端分離的，后端只需要返給給前端數據即可，這個時候我們就需要使?@ResponseBody 注解了。

這我們已經在前面演示了。
這里再穩(wěn)固一下。?

?當我們加上 @ResponseBody 注解的時候，它認為我們返回的是一個非靜態(tài)頁面數據。
它就會直接顯示

既可以修飾類，也可以修飾方法。
修飾類，表示 類中所有的方法的返回值，都是一個非靜態(tài)頁面的數據。
修飾方法，表示 該方法的返回值，是一個非靜態(tài)頁面的數據。
?
但是，還是有點麻煩。。
畢竟，還是需要寫兩個注解。
?
于是，Spring MVC 又提供了一個新的注解。
結合了 @Controller 和 @ResponseBody，兩者之間的功能。
這個新的組合注解叫做 @RestController

簡單來說：可以將 @RestController 理解為是 HTTP 的 controller 類注解。

這是目前主流的使用注解。
?
那么，什么@RestController 能夠代替兩個注解的工作呢？
這四因為 @RestController 里面實現了這兩個 注解。
【按住 Ctrl，左鍵點擊 RestController，就可以進入源碼?！?/span>

練習

實現計算器功能 - form 表單

可使? postman 傳遞參數，或使? form 表單的?式提交參數。
前端??代碼：

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport"
          content="width=device-width, user-scalable=no, initialscale=1.0, maximum-scale=1.0, minimum-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <title>計算器示例</title>
</head>
<body>
<form action="/calc">
    <h1>計算器</h1>
    數字1：<input name="num1" type="text"><br>
    數字2：<input name="num2" type="text"><br>
    <input type="submit" value=" 點擊相加 ">
</form>
</body>
</html>

下面來看具體的實現步驟。

是不是非常簡單？！
我們不用再去 寫一些獲取參數的操作了，直接當成一個普通方法來處理.
需要強調的是：參數名稱 要與前端傳輸的參數名稱 一致，
不一樣也行，使用 @RequestParam 來進行重命名操作，記得將 required 屬性置為 false。
?
另外，方法的參數，需要使用包裝類。
如果使用 基礎數據類型來接收前端參數，如果前端返回一個 null，就會 數值 與 類型不匹配。
還有，因為使用 包裝類，所以允許前端返回一個 null 值。
因此，我們需要做一步 校驗（驗證 數據是否非空），避免造成空指針異常。
所以，我們再稍微修改一下代碼。

?此時，計算器的功能，才算真正完成了！

這里，我們還可做一個業(yè)務優(yōu)化。
在顯示結果的頁面，設置一個返回鍵。

拓展： Spring MVC 的 熱部署 設置

在經過上述的學習，我們不難發(fā)現：每次修改代碼之后，都需要重啟 項目。
這就麻煩！這里我們就可以通過設置熱部署來解法雙手。

在這里需要明白一件事：
為什么需要重啟項目，我們的效果才是根據最新的代碼來呈現的。

因此，作為一個“合格”的程序員，怎么可以讓自己那么累呢！
當然是 配置熱部署。讓它 “實時更新” target 目錄中的內容。

“實時更新”：修改完代碼之后，大概在 3 ~ 4 s 之后，才會熱部署完成。
即：自動更新了 target 中的內容（實際上，自動生成了一個新的target。將原來的覆蓋，所以才會那么耗時！）
?
熱部署的運行原理：
它會檢測 當前源代碼中，有沒有發(fā)生改動？
如果改動了，熱部署 就會拿到一個 改動事件。
在拿到源代碼改動事件之后，它會自動幫我們重啟項目。
?
雖然，還是通過重啟項目的方式，來讓改動的代碼生效。
但是！我們不需要再去手動點擊重啟了！
?
自動重啟項目消耗的時間，前面也說了。
大概 3~4 s 的樣子，熱部署就完成了。
此時，你再去訪問，看到的效果，就是最新的了。

下面，我們就來配置熱部署。?

1.添加熱部署框架?持

在 pom.xml 中添加如下框架引?：
PS: 一般我們在創(chuàng)建 Spring Boot（Spring MVC） 項目的時候，就已經添加了這個框架。

如果你忘記加了，或者是一個老項目，也不要緊。
添加 lombok 依賴，插件 Edit Starters
可以快捷插入所需的框架支持

2、Settings 開啟項??動編譯

3.開啟運?中熱部署

剛才開啟的是 idea 的熱部署。
和 程序運行熱部署設置沒關系。
設置情況分為兩種。

1、低版本 Idea 設置（IntelliJ IDEA 2021.2 之前的版本）

?2、?版本 Idea 設置（IntelliJ IDEA 2021.2 之后版本）

?經過上述操作，我們的熱部署就完成了。

這是因為有些人的idea，即使前面三步都完成了，熱部署仍然無法生效。
使用 debug 運行項目，就不會存在這個問題。

當然 你 使用 run ，熱部署也能生效。
那就隨便了。

效果展示

看到這個效果，說明熱部署已經設置成功了，并且已經運行了。
以后，就不用我們去手動重啟項目了。

模擬登錄功能，前端使? ajax，后端返回 json 給前端。

前端代碼

<!doctype html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport"
          content="width=device-width, user-scalable=no, initialscale=1.0, maximum-scale=1.0, minimum-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <script src="js/jquery-1.9.1.min.js"></script>
    <title>Document</title>
    <script>
        // ajax 提交
        function mysub(){
            //1、判空
            // 輸入框中的值
            let username =  jQuery('#username');
            let password = jQuery('#password');
            // jQuery.trim 去空格
            if(jQuery.trim(username.val()) == ''){
                alert("請輸入用戶名！");
                return;
            }
            if(jQuery.trim(password.val()) == ''){
                alert("請輸入密碼！");
                return;
            }
            jQuery.ajax({
                // 請求使用方法
                type: "POST",
                //  映射方法路徑
                url: '/user/login2',
                // 請求正文
                data: {"username": username.val(),"password": password.val()},
                // 除了 服務器范湖的結果
                success: function(result){
                    alert(result);
                }
            });
        }
    </script>
</head>
<body>
<div style="text-align: center;">
    <h1>登錄</h1>
    ?戶：<input id="username">
    <br>
    密碼：<input id="password" type="password">
    <br>
    <input type="button" value=" 提交 " onclick="mysub()"
           style="margin-top: 20px;margin-left: 50px;">
</div>
</body>
</html>

將上述的代碼，放入一個 HTML 文件中。

?需要注意的是 ajax 是需要依賴于 jQuery 的。
所以我創(chuàng)建一個 js 包，用來存儲 jQuery。

后端代碼

效果圖

小拓展：前端返回一個json數據，后端可以接收。

前面，我們是直接接收 參數的。

要想接收一個 JSON 數據，是需要借助 @RequestBody 注解的。
問題，就在于，前端如何構造一個 JSON 數據。（了解）

后端代碼支持獲取 JSON 格式的數據，前端整體不改，值修改訪問路徑。

?

得出結論：
前后端的數據格式要匹配。
不然會報錯！
回到最初的問題：
前端如果構造一個Json格式的數據。得出結論：
前端在構造 json 格式的數據的時候，不僅要將返回的數據設置成 json格式的數據，并且返回值的類型也需要設置成 JSON 格式。
?
而后端在接收 json 數據的時候，需要使用 @RequestBody 注解

請求轉發(fā)或請求重定向 - 重點

forward VS redirect

return 不但可以返回?個視圖，還可以實現跳轉，跳轉的?式有兩種：
1、forward 是請求轉發(fā)；
2、redirect：請求重定向。

forward 請求轉發(fā) 實現

當我們訪問到 myForward 方法，執(zhí)行到return 語句的時候。
請求轉發(fā)，是 服務器端的一個行為。

服務器端會訪問這個頁面，并且將頁面的數據 返回給 客戶端。
?
這個就好比，我們在大學時期，我們想吃飯的時候，叫室友爸爸帶飯一樣。
此時，我們就相當于是客戶端，室友爸爸就是服務器。
食堂的飯菜，就是想要的網頁數據。
當我們向室友爸爸提出帶飯請求，室友爸爸接收到請求之后，他就會去訪問食堂大媽。
獲取 大媽手中的飯菜，將其帶回給我們。
?
簡單來說：服務器端（室友）就是 一個中間商，客戶端（我們）想要獲取的數據（飯菜），并非來自服務器端自身。
只是說：不用我們（客戶端）去打飯（獲取數據），他（服務器端）會幫我們找到它，將它帶回來給我們。

由張圖我們可以看出，對于 目標服務的數據，是共享的。
無論是誰訪問，都可以訪問該頁面的數據。
?
我們再來看看fiddler抓包的結果

?除了使用注解的方式來實現 請求轉發(fā)，我們還可以基于 Servlet API 來實現請求轉發(fā)

?文章來源地址http://www.zghlxwxcb.cn/news/detail-552579.html

相比與注解，servlet 就比較麻煩了！
servlet，先是要獲取請求調度器，來獲取轉發(fā)資源，最后，通過 forward方法，將 請求獲取的資源，寫入 響應中。
?
而 Spring MVC 直接一個鍵值對，就完事了。
?

其實最簡單直接的方法，就是 通過 return 直接返回 頁面。

?至于效果，我就不展示了。
前面已經玩過了。

redirect：請求重定向 實現

請求重定向，也有兩種實現方式。
1、 注解方式

?通過上述操作，展示出來的效果。其實就已經體現出 轉發(fā) 與 重定向的區(qū)別了。
轉發(fā)，它的URL 是不會改變的；
重定向，URL地址變成了 訪問頁面的地址
這是其一。

其二：
轉發(fā)，瀏覽器只需要發(fā)送一條請求，就能獲取到網頁信息。
重定向，瀏覽器需要發(fā)送兩條請求，才能獲取網頁信息。

?還是舉那個例子：
我們代表客戶端，室友弟弟代表服務器端，飯菜就是網頁數據。
此時，我們像往常一樣，向室友爸爸發(fā)送一個 帶飯請求。
但是！他這個弟弟居然居然拒絕了，而且說是要去約會?。。?br> 告訴我們，只能自己去食堂買飯了。（這就是第一個請求，返回的302響應）
那我們還能怎么辦，當然弟弟的幸福重要。。。
于是我們只能自己去買飯了。（這就對應著第二個請求）
?
簡單來說：
重定向，是前端的一種行為。
直白來說：前端 向 后端索要數據，后端只告訴了它去哪里拿，前端需要自己去獲取。

?這就好比 問路，別人只告訴了我們怎么走，并不會領著我們去往目的地。
【PS：別人怕你套路他，你也怕別人套路你】
需要注意的是：重定向，數據是不共享的。
就是我給你的地址，你能不能訪問到數據，是不確定的。
萬一，這份數據是需要權限的，但是你沒有，那就訪問不了了。
或者這網站，被注銷了，你也是訪問不了的！

2、 Servlet API

區(qū)別總結

forward 和 redirect 具體區(qū)別如下：
1、 請求重定向（redirect）將請求重新定位到資源；請求轉發(fā)（forward）服務器端轉發(fā)。

直白來說：定義不同。
請求轉發(fā)（Forward）：發(fā)生在服務端程序內部，當服務器端收到一個客戶端的請求之后，會先將請求，轉發(fā)給目標地址，再將目標地址返回的結果轉發(fā)給客戶端。
重定向：甩給你目標地址，其它事情與我無關。

2、請求重定向地址發(fā)?變化，請求轉發(fā)地址不發(fā)?變化。
3、重定向瀏覽器會發(fā)送兩條請求，轉發(fā)，只有一條請求。
4、重定向，數據不共享；轉發(fā)，數據共享。
5、 請求重定向與直接訪問新地址效果一致，不存在原來的外部資源不能訪問；請求轉發(fā)服務器端轉發(fā)有可能造成原外部資源不能訪問。

請求轉發(fā) forward 導致的問題:
請求轉發(fā)如果資源和轉發(fā)的??不在?個?錄下，會導致外部資源不可訪問。

?

我們寫的這種，是相對路徑。
如果訪問的資源，分級（分包）存儲。
此時，就需要根據當前路徑做出改變。
保險的做法就是寫絕對路徑。
當然，相對路徑寫起來要簡單一些。
看個人選擇。
?
重定向，是直接給你目標訪問的地址，它本身的地址并沒有被改變。
而 轉發(fā)，假設我們 實現請求轉發(fā)的方法，是處于 一級路徑，訪問的源在 二級目錄。
所以，它的地址發(fā)生了改變，從二級目錄 變成 一級目錄，
那么，一級目錄中的相對資源就會丟失了。
這就是 請求轉發(fā)存在的一個問題。
?

這就跟借錢一樣。
重定向：
張三 找李四 借錢，但李四確實沒錢；
李四 告訴 張三，去王五那里看看。
張三接到了。
結果張三跑了。。。
這個時候，李四是不擔責任了。
因為 錢 是張三借的。
?
轉發(fā)：
張三 找李四 借錢，但李四確實沒錢；
李四 去找王五那里借了一些錢，然后，給了張三。
結果張三跑了。。。
王五找誰還？
肯定找李四?。∫驗槭?李四找他借的錢。
李四肯定是脫不了關系的?。?！

請求轉換，就存在這樣的問題。
如果目錄的層級是不一樣的，那么它的相對地址也是不一樣的。
此時，使用請求轉發(fā)，就有可能出問題。

6、代碼實現不同。

這個很明顯！
關鍵字都不一樣，好吧?。。?！
一個 forward（轉發(fā)），一個 redirect（重定向）

?

到了這里，關于Spring MVC 程序開發(fā)的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網！