模型 - 視圖 - 控制器（ MVC ）是 80 年代 Smalltalk-80 出現的一種軟件設計模式，現在已經被廣泛的使用。

???? ? ? 1 、模型（ Model ）
　　模型是應用程序的主體部分。模型表示業務數據，或者業務邏輯 .
2 、視圖（ View ）
　　視圖是應用程序中用戶界面相關的部分，是用戶看到并與之交互的界面。
3 、控制器（ controller)
　控制器工作就是根據用戶的輸入，控制用戶界面數據顯示和更新 model 對象狀態。
MVC 式的出現不僅實現了功能模塊和顯示模塊的分離，同時它還提高了應用系統的可維護性、可擴展性、可移植性和組件的可復用性
　　早期的程序中，如果不注意對數功能和顯示的解耦合，常常會導致程序的復雜及難以維護。很多 VB,Delphi 等 RAD 程序都有這種問題。甚至現在的 C#,Java 有時候也會出現把業務邏輯寫在顯示模塊中的現象
　　管 MVC 設計模式很早就提出，但在 Web 項目的開發中引入 MVC 卻是步履維艱。主要原因：一是在早期的 Web 項目的開發中，程序語言和 HTML 的分離一直難以實現。 CGI 程序以字符串輸出的形式動態地生成 HTML 內容。后來隨著腳本語言的出現，前面的方式又被倒了過來，改成將腳本語言書寫的程序嵌入在 HTML 內容中。這兩種方式有一個相同的不足之處即它們總是無法將程序語言和 HTML 分離。二是腳本語言的功能相對較弱，缺乏支持 MVC 設計模式的一些必要的技術基礎。

??????? mode1?1 是一個以 JSP 文件為中心的模式，在這種模式中 JSP 頁面不僅負責表現邏輯，也負責控制邏輯。專業書籍上稱之為邏輯耦合在頁面中，這種處理方式，對一些規模很小的項目如：一個簡單的留言簿，也沒什么太大的壞處，實際上，人們開始接觸一些對自己來說是新的東西的時候，比如，用 JSP 訪問數據庫時，往往喜歡別人能提供一個包含這一切的單個 JSP 頁面，因為這樣在一個頁面上他就可以把握全局，便于理解。但是，用 Model?1 模式開發大型時，程序流向由一些互相能夠感知的頁面決定，當頁面很多時要清楚地把握其流向將是很復雜的事情，當您修改一頁時可能會影響相關的很多頁面，大有牽一發而動全身的感覺，使得程序的修改與維護變得異常困難；還有一個問題就是程序邏輯開發與頁面設計糾纏在一起，既不便于分工合作也不利于代碼的重用，這樣的程序其健壯性和可伸縮性都不好。 Grady?Booch 等人在 UML 用戶指南一書中，強調建模的重要性時，打了一個制作狗窩、私人住宅、和大廈的形象比喻來說明人們處理不同規模的事物時應該采用的合理方法一樣，人們對不同規模的應用程序也應該采用不同的模式

為了克服 Model?1 的缺陷，人們引入了 Model?2

它引入了 \" 控制器 \" 這個概念，控制器一般由 servlet 來擔任，客戶端的請求不再直接送給一個處理業務邏輯的 JSP 頁面，而是送給這個控制器，再由控制器根據具體的請求調用不同的事務邏輯，并將處理結果返回到合適的頁面。因此，這個 servlet 控制器為應用程序提供了一個進行前 - 后端處理的中樞。一方面為輸入數據的驗證、身份認證、日志及實現國際化編程提供了一個合適的切入點；另一方面也提供了將業務邏輯從 JSP 文件剝離的可能。業務邏輯從 JSP 頁面分離后， JSP 文件蛻變成一個單純完成顯示任務的東西，這就是常說的 View 。而獨立出來的事務邏輯變成人們常說的 Model, 再加上控制器 Control 本身，就構成了 MVC 模式。實踐證明， MVC 模式為大型程序的開發及維護提供了巨大的便利。 ?

其實， MVC 開始并不是為 Web 應用程序提出的模式，傳統的 MVC 要求 M 將其狀態變化通報給 V ，但由于 Web 瀏覽器工作在典型的拉模式而非推模式，很難做到這一點。因此有些人又將用于 Web 應用的 MVC 稱之為 MVC2 。正如上面所提到的 MVC 是一種模式，當然可以有各種不同的具體實現，包括您自己就可以實現一個體現 MVC 思想的程序框架， Struts 就是一種具體實現 MVC2 的程序框架。它的大致結構如圖三所示

?

?

圖基本勾勒出了一個基于 Struts 的應用程序的結構，從左到右，分別是其表示層（ view ）、控制層 (controller) 、和模型層 (Model) 。其表示層使用 Struts 標簽庫構建。來自客戶的所有需要通過框架的請求統一由叫 ActionServlet 的 servlet 接收（ ActionServlet?Struts 已經為我們寫好了，只要您應用沒有什么特別的要求，它基本上都能滿足您的要求），根據接收的請求參數和 Struts 配置 (struts-config.xml) 中 ActionMapping ，將請求送給合適的 Action 去處理，解決由誰做的問題，它們共同構成 Struts 的控制器。 Action 則是 Struts 應用中真正干活的組件，開發人員一般都要在這里耗費大量的時間，它解決的是做什么的問題，它通過調用需要的業務組件（模型）來完成應用的業務，業務組件解決的是如何做的問題，并將執行的結果返回一個代表所需的描繪響應的 JSP （或 Action ）的 ActionForward 對象給 ActionServlet 以將響應呈現給客戶。 ? 過程如圖所示： ?

?

這里要特別說明一下的是：就是 Action 這個類，上面已經說到了它是 Struts 中真正干活的地方，也是值得我們高度關注的地方。 將業務對象從 Action 分離出來后有利于它的重用，同時也增強了應用程序的健壯性和設計的靈活性。因此，它實際上可以看作是 Controller 與 Model 的適配器，如果硬要把它歸于那一部分，筆者更傾向于后一種看法，即它是 Controller 的一部分，換句話說，它不應該包含過多的業務邏輯，而應該只是簡單地收集業務方法所需要的數據并傳遞給業務對象。

上面這樣簡單的描述，初學者可能會感到有些難以接受，下面舉個比較具體的例子來進一步幫助我們理解。如：假設，我們做的是個電子商務程序，現在程序要完成的操作任務是提交定單并返回定單號給客戶，這就是關于做什么的問題，應該由 Action 類完成，但具體怎么獲得數據庫連接，插入定單數據到數據庫表中，又怎么從數據庫表中取得這個定單號（一般是自增數據列的數據），這一系列復雜的問題，這都是解決怎么做的問題，則應該由一個（假設名為 orderBo ）業務對象即 Model 來完成。 orderBo 可能用一個返回整型值的名為 submitOrder 的方法來做這件事， Action 則是先校驗定單數據是否正確，以免常說的垃圾進垃圾出；如果正確則簡單地調用 orderBo 的 submitOrder 方法來得到定單號；它還要處理在調用過程中可能出現任何錯誤；最后根據不同的情況返回不同的結果給客戶。

?

Struts由入門到精通（第二章）-應用框架 mvc和model2