MVC設計模式
在傳統的Web應用開發中，架構模式基本一致：
- 數據實體：POJO
- 數據層：DAO
- 業務層：Service
- 控制層：Servlet
- 表示層（頁面層）：JSP頁面或HTML頁面
這種架構模式就是MVC設計模式，它是軟件工程中的一種架構模式，強制性地使軟件系統的輸入、處理和輸出分開，把系統分為三個基本部分：模型(Model)、視圖(View)、控制器（Controller）
MVC模式中各部分的職責
Model：模型對象擁有最多的處理任務，是應用程序的主體部分，它負責數據邏輯（業務邏輯）的處理和實現數據庫的操作。在項目中除了控制層的控制器，幾乎每一個Bean組件都屬於模型，比如Service層、DAO層，以及POJO實體類等。
View：負責格式化數據並把它們呈現給用戶，包括數據展示、用戶交互、數據驗證、頁面設計等功能。說白了就是離用戶最近的、展示給人們看的，比如HTML或者JSP頁面。
Controller：負責接收並轉發請求，對請求處理之后拿到響應結果，指派要使用的視圖（類似於指定Servlet跳轉到不同的頁面進行展示），將響應結果返回給客戶端。對應的組件一般是Servlet，很少用JSP頁面直接處理其他頁面過來的請求。
JSP Model1
JSP+JavaBean
在一個項目中，如果業務流程比較簡單的時候，可以把控制器的功能交給視圖，項目架構中只有視圖和模型，沒有控制器。
Model1模式的基礎是JSP，它由JSP和JavaBean組成，JSP從HTTPRequest中獲取所需要的數據，並調用JavaBean進行業務邏輯的處理，然后通過HTTPResponse將結果返回給前端瀏覽器。可見，Model1一定程度上實現了MVC，只不過將控制層和視圖層統一定位到JSP頁面，JavaBean依然充當模型組件。這種模式下JSP身兼多職，既要負責視圖層的數據展示，又要負責業務流程控制，結構較為混亂，也不是我們所希望的松耦合架構，所以在大型項目中或者當業務流程比較復雜的時候不建議這樣做。
JSP Model2
JSP+Servlet+JavaBean
當業務流程比較復雜的時候，就需要把業務流程控制交給專門的控制器，JSP只專注於視圖的渲染展現即可。這種模式就是JSP Model2，即JSP+Servlet+JavaBean，也就是典型的MVC設計模式。
相比於Model1，Model2是將控制層單獨划分出來，以Servlet的形式存在於項目架構中，負責業務流程的控制，接收請求，創建所需的JavaBean組件，並將處理后的數據返回給視圖（JSP/HTML）進行結果渲染展示。這樣的結構比較清晰，效果明顯優化很多，並且結合Spring的IoC和AOP，也是一個松耦合的架構模式。所以，除非項目特別簡單，一般情況下推薦使用JSP Model2。
MVC處理流程及優缺點
通過以上對MVC的了解，我們不妨分析一下MVC的處理過程：
首先視圖提供系統與用戶交互的界面，並發送用戶的輸入給控制器；
控制器接收到用戶的請求，根據判斷，決定調用哪個模型的哪個方法進行處理；
模型被控制器調用，根據控制器的指令進行相應的業務邏輯處理，並返回處理結果（數據）；
控制器根據返回的結果，調用相應的視圖來渲染、格式化模型返回的數據；
視圖響應給客戶端瀏覽器。
以上即是MVC的處理流程以及各部分之間的關系，那么任何一件事都會有利有弊，我們再分析一下MVC模式的優缺點。
優點：
可以多視圖共享多個模型，大大提高了代碼的復用性；
MVC的三個模塊相互獨立，松耦合架構；
控制器提高了應用程序的靈活性和可配置性；
有利於項目的管理和維護。
缺點：
原理較復雜，實現起來固然沒有JSP+JavaBean的方式來得快；
增加了系統結構和實現的復雜性；
視圖對模型數據的訪問效率較低。
總之，我們可以通過MVC的設計模式，最終打造出一個松耦合+高復用+高適用性等的完美架構，這也是架構設計的目標之一。但是，對於MVC來說，它並不適用於小型的項目，花費大量的時間將MVC應用到項目中通常得不償失，誇張點說，可能搭建三層架構、構建MVC開發環境的時間，都可以實現整個項目功能了。所以，是否使用MVC模式，應該根據實際場景來決定。
Spring MVC
springmvc框架的請求處理流程
Spring MVC也是一個基於請求驅動的Web框架，並且也使用了前端控制器模式來進行設計，再根據請求映射規則分發給相應的頁面控制器（處理器）來進行處理，下面具體分析一下它的處理步驟：
首先用戶發送請求到前端控制器（DispatcherServlet），前端控制器根據請求信息（比如URL）決定將請求分發給哪個頁面控制器（Controller）來處理。對應上圖中的步驟1、2。
頁面控制器接收到請求之后，進行業務處理，處理完畢之后返回一個ModelAndView。對應上圖中的步驟3、4、5。
前端控制器將控制權收回，然后根據返回的邏輯視圖名，通過視圖解析器選擇真正的視圖，將模型數據傳入供其渲染展示。對應上圖中的步驟6、7。
前端控制器再次收回控制權，將響應結果返回給瀏覽器客戶端，至此整個流程結束。對應上圖中的步驟8。
Spring MVC框架的體系結構
客戶端發出HTTP請求，Web應用服務器接收此請求。如匹配DispatcherServlet的請求映射路徑，則Web容器將該請求轉交給DispatcherServlet處理；
DispatcherServlet拿到請求之后，根據請求的信息（URL、請求參數、HTTP方法等）及HandlerMapping的配置找到處理請求的處理器（Handler）；
當DispatcherServlet找到相應的Handler之后，通過HandlerAdapter對Handler進行封裝，再以統一的適配器接口調用Handler。HandlerAdapter可以理解為真正使用Handler來干活的人。
在請求信息真正到達調用Handler的處理方法之前的這段時間，Spring MVC還完成了很多工作，它會將請求信息以一定的方式轉換並綁定到請求方法的入參，對於入參的對象會進行數據轉換、數據格式化以及數據校驗等。這些都做完以后，最后才真正調用Handler的處理方法進行相應的業務邏輯處理。
處理器完成業務處理之后，將一個ModelAndView對象返回給DispatcherServlet，其中包含了邏輯視圖名和模型數據信息。
DispatcherServlet通過ViewResolver將邏輯視圖名解析為真正的視圖對象View，可以是JSP、HTML、XML、PDF、JSON等等，Spring MVC均可靈活配置，在以后會介紹。
得到真正的視圖對象之后，DispatcherServlet會根據ModelAndView對象中的模型數據對View進行視圖渲染。
最終客戶端獲得響應消息。
Spring MVC框架的特點
- 角色划分清晰。Model、View、Controller各司其職，耦合度較低。
- 靈活的配置功能。Spring的核心是IoC和AOP，統一可以實現在MVC上，把各種類當作Bean組件配置在Spring容器中。
- 提供了大量的接口和實現類，方便各種場景的開發。
- 真正做到與View層的實現無關。
- 結合Spring的依賴注入，更好地應用了面向接口編程的思想。
- 可以與Spring天衣無縫的整合
Spring MVC需要的jar包
參考：
https://blog.csdn.net/wzy18210825916/article/details/82799764