MVC
View 檢視 ： Model2 JSP
解析模型的資料
產生HTML響應
請求模型的更新
傳送使用者輸入給控制器

Controler 控制器：Model2 Servlet
接收並驗證HTTP請求的資料
將使用者資料與模型的更新相對映
選擇用於響應的檢視

Model 模型：Model2 JavaBean （資料模型 JavaBean 和 業務邏輯模型 JavaBean）
封裝應用狀態
響應狀態查詢
暴露應用功能
通知檢視改變


互動關係：
1. 首先是展示檢視給使用者，使用者在這個檢視進行操作，並填寫一些業務資料
2. 然後使用者用單擊提交按鈕，發出請求
3. 檢視發出的使用者請求會達到控制器，在請求中包含了想要完成什麼樣的業務功能及相關資料
4. 控制器處理使用者請求，會把請求中的資料進行封裝，然後選擇並呼叫合適的模型，請求模型進行狀態更新，然後選擇接
下來要展示給使用者的檢視。
5. 模型處理使用者請求的業務功能，同時進行模型狀態的維護和更新。
6. 當模型狀態發生改變的時候，模型會通知響應的檢視，告知檢視它的狀態發生了改變。
7. 檢視接到模型的通知後，會向模型進行狀態查詢，獲取需要展示的資料，然後按照檢視本身的展示方式，把這些資料展示出來。

MVC 的核心手段是解耦
模型和檢視是解耦的

Model2時期的MVC
Servlet+JSP+JavaBean
缺點： 1. 流程凌亂 servlet在完成對使用者的處理後，下一個頁面是誰？如何跳轉，這些都是在servlet程式碼完成，導致
Servlet既要處理請求，還有負責頁面的流程，功能不夠單一，整個系統的頁面流程很難把握，頁面流程
都被分散到各個Serlet裡面了
2. 資料傳遞無序。
3. 缺乏輔助功能，沒有統一的分發排程、驗證框架、國際化、本地化、例外訊息處理等

Struts1時期的MVC
缺點： 1. Action實現類必須繼承Struts1中的Action，降低了靈活性
2. 一個應用中，只能使用一個單一的ActionServlet，導致配置衝突
3. Action的API同 HttpServletRequest和HttpServletResponse是耦合的，單元測試困難
4. 頁面傳值的JavaBean必須繼承Struts1中的FormBean，而其本質就是一個 JavaBean
5. 沒有獨立的攔截器模型，類似面向切面 （AOP）的操作都要寫成 Filter，使用和配置都較弱


Struts2 MVC

檢視（結果Result） -》 提交請求 -》 控制器（FilterDispatcher）
控制器（FilterDispatcher）-》根據URL呼叫動作-》模型（動作Action）
模型（動作Action）-》選擇結果-》檢視（結果Result）


控制器--FilterDispatcher 負責根據使用者提交的URL和struts.xml中的配置，選擇Action
其實就是一個過濾器，體現了J2EE核心設計模式中的前端控制器模式

動作---Action 請求經過FilterDispatcher，分發到合適的動作Action。 Action負責把使用者的引數組裝成合適的數
據模型，並呼叫相應的業務邏輯，進行真正的功能處理，然後獲取下一個檢視展示所需要的資料。
與Servlet API 解耦，不需要直接去引用和使用HttpservletRequest與HttpServletResponse介面，方便單元測試

檢視---Result 展示動作中獲取到的資料展現給使用者。 jsp 模板freemarker、velocity、圖表jfreechart、報表
JasperReports、XML轉為為HTML的XSLT等。