在傳統的Web應用開發中，架構模式基本一緻：
資料實體：POJO
資料層：DAO
業務層：Service
控制層：Servlet
表示層（頁面層）：JSP頁面或HTML頁面
這種架構模式就是MVC設計模式，它是軟體工程中的一種架構模式，強制性地使軟體系統的輸入、處理和輸出分開，把系統分為三個基本部分：模型(Model)、視圖(View)、控制器（Controller）
Model：模型對象擁有最多的處理任務，是應用程式的主體部分，它負責資料邏輯（業務邏輯）的處理和實作資料庫的操作。在項目中除了控制層的控制器，幾乎每一個Bean元件都屬于模型，比如Service層、DAO層，以及POJO實體類等。
View：負責格式化資料并把它們呈現給使用者，包括資料展示、使用者互動、資料驗證、頁面設計等功能。說白了就是離使用者最近的、展示給人們看的，比如HTML或者JSP頁面。
Controller：負責接收并轉發請求，對請求處理之後拿到響應結果，指派要使用的視圖（類似于指定Servlet跳轉到不同的頁面進行展示），将響應結果傳回給用戶端。對應的元件一般是Servlet，很少用JSP頁面直接處理其他頁面過來的請求。
JSP+JavaBean
在一個項目中，如果業務流程比較簡單的時候，可以把控制器的功能交給視圖，項目架構中隻有視圖和模型，沒有控制器。
Model1模式的基礎是JSP，它由JSP和JavaBean組成，JSP從HTTPRequest中擷取所需要的資料，并調用JavaBean進行業務邏輯的處理，然後通過HTTPResponse将結果傳回給前端浏覽器。可見，Model1一定程度上實作了MVC，隻不過将控制層和視圖層統一定位到JSP頁面，JavaBean依然充當模型元件。這種模式下JSP身兼多職，既要負責視圖層的資料展示，又要負責業務流程控制，結構較為混亂，也不是我們所希望的松耦合架構，是以在大型項目中或者當業務流程比較複雜的時候不建議這樣做。
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的三個子產品互相獨立，松耦合架構；
控制器提高了應用程式的靈活性和可配置性；
有利于項目的管理和維護。
缺點：
原理較複雜，實作起來固然沒有JSP+JavaBean的方式來得快；
增加了系統結構和實作的複雜性；
視圖對模型資料的通路效率較低。
總之，我們可以通過MVC的設計模式，最終打造出一個松耦合+高複用+高适用性等的完美架構，這也是架構設計的目标之一。但是，對于MVC來說，它并不适用于小型的項目，花費大量的時間将MVC應用到項目中通常得不償失，誇張點說，可能搭建三層架構、建構MVC開發環境的時間，都可以實作整個項目功能了。是以，是否使用MVC模式，應該根據實際場景來決定。
Spring MVC也是一個基于請求驅動的Web架構，并且也使用了前端控制器模式來進行設計，再根據請求映射規則分發給相應的頁面控制器（處理器）來進行處理，下面具體分析一下它的處理步驟：
首先使用者發送請求到前端控制器（DispatcherServlet），前端控制器根據請求資訊（比如URL）決定将請求分發給哪個頁面控制器（Controller）來處理。對應上圖中的步驟1、2。
頁面控制器接收到請求之後，進行業務處理，處理完畢之後傳回一個ModelAndView。對應上圖中的步驟3、4、5。
前端控制器将控制權收回，然後根據傳回的邏輯視圖名，通過視圖解析器選擇真正的視圖，将模型資料傳入供其渲染展示。對應上圖中的步驟6、7。
前端控制器再次收回控制權，将響應結果傳回給浏覽器用戶端，至此整個流程結束。對應上圖中的步驟8。
用戶端發出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進行視圖渲染。
最終用戶端獲得響應消息。
角色劃厘清晰。Model、View、Controller各司其職，耦合度較低。
靈活的配置功能。Spring的核心是IoC和AOP，統一可以實作在MVC上，把各種類當作Bean元件配置在Spring容器中。
提供了大量的接口和實作類，友善各種場景的開發。
真正做到與View層的實作無關。
結合Spring的依賴注入，更好地應用了面向接口程式設計的思想。
可以與Spring天衣無縫的整合
參考：
https://blog.51cto.com/aeolian/2853207