一. 目的
提高代碼重用、增加開發速度和減少維護修改量已經成為現軟體開發模式中日益提升的需求。架構、模型和介面也就隨此孕育而生。
MVC是一個設計模式，它強制性的使應用程式的輸入、處理和輸出分開。使用MVC應用程式被分成三個核心組件：模型、視圖、控制器。它們各自處理自己的任務。使用MVC設計模式能夠使得開發人員可以把精力集中在如何解決實際業務問題上。
為什麼要使用 MVC
大部分Web應用程式都是用像JSP，ASP，PHP，或者CFML這樣的過程化語言來建立的。它們將像資料庫查詢語句這樣的資料層代碼和像HTML這樣的展示層代碼混在一起。經驗比較豐富的開發人員會將資料從展示層分離開來，但這通常不是很容易做到的，它需要精心的計劃和不斷的嘗試。MVC從根本上強制性的將它們分開。儘管構造MVC應用程式需要一些額外的工作，但是它給我們帶來的好處是無庸質疑的。
首先，最重要的一點是多個視圖能共用一個模型，正如我所提及的，現在需要用越來越多的方式來訪問你的應用程式。對此，其中一個解決之道是使用MVC，無論你的使用者想要Flash介面或是 WAP 介面；用一個模型就能處理它們。由於你已經將資料和商務規則從展示層分開，所以你可以最大化的重用你的代碼了。
由於模型返回的資料沒有進行格式化，所以同樣的構件能被不同介面使用。例如，很多資料可能用HTML來表示，但是它們也有可能要用Macromedia Flash和WAP來表示。模型也有狀態管理和資料持久性處理的功能，例如，基於會話的購物車和電子商務過程也能被Flash網站或者無線連網的應用程式所重用。
因為模型是自包含的，並且與控制器和視圖相分離，所以很容易改變你的應用程式的資料層和商務規則。如果你想把你的資料庫從MySQL移植到Oracle，或者改變你的基於RDBMS資料來源到LDAP，只需改變你的模型即可。一旦你正確的實現了模型，不管你的資料來自資料庫或是LDAP伺服器，視圖將會正確的顯示它們。由於運用MVC的應用程式的三個組件是相互對立，改變其中一個不會影響其它兩個，所以依據這種設計思想你能構造良好的松偶合的構件。
對我們來說，控制器的也提供了一個好處，就是可以使用控制器來聯結不同的模型和視圖去完成使用者的需求，這樣控制器可以為構造應用程式提供強有力的手段。給定一些可重用的模型和視圖，控制器可以根據使用者的需求選擇模型進行處理，然後選擇視圖將處理結果顯示給使用者。
二. B/S 構架MVC設計模式圖
無法顯示，使用文字簡單描述：
資訊層:關聯式資料庫
資料持久化層: DAO
模型層:業務對象(Business Object)、商務邏輯、業務代理介面、控制器
視圖層：視圖
客戶層：IE
三. 設計模式描述
根據B/S三層構架設計模式，我們把資料庫資訊層單獨放置為底層，資料持久化層、模型層和控制器層視為中介層，視圖層為用戶端顯示操作介面，處於最上層，也是程式直接接受操作層。
3.1. 資料的持久化
持久化意味著通過手工或者其他方式輸入到應用中的資料能夠在應用結束運行後依然存在。這就需要資料被持久化到資料庫或磁碟檔案。
物件導向的開發方法是當今的主流，但是同時不得不使用關係型資料庫，在企業級開發的環境中，對象——系的映射（Object - Relation Mapping， 簡稱ORM）也就成為持久化操作的一個重要環節。圍繞ORM和持久化資料的訪問，在軟體領域中發展起來了一種Data Access Objects（Data Access Object， 簡稱DAO）設計模式。
對於java 應用，可以直接通過JDBC 編程來訪問資料庫，在企業級應用開發中，可以通過JDBC編程來開發自己的DAO API，把資料訪問操作封裝起來，供業務層統一調用。
3.2. 業務對象
業務對象（Business Object， 簡稱 BO），即是對真實世界的實體的軟體抽象。它可以代表業務領域中的人、地點、事物或概念。業務對象包括狀態和行為。
如果一個類可以作為業務對象，那麼它應該具有以下特徵：
a、包含狀態和行為
b、代表業務領域的人、地點、事物或概念
c、可以重用
業務對象可分為三種類型：
a、實體業務對象
b、過程業務對象
c、事件業務對象
通過不同類型的業務對象相互組合調用，構成商務邏輯層，是模型層核心部分。
3.3. 業務代理介面
業務代理介面直接存取、組合業務對象和持久化架構，處理實際的商務邏輯，使用業務代理介面，可以讓控制器使用這些代理介面，而不必直接和持久化架構互動。這種做法有助於消弱上層web應用和持久化架構之間的關係，提高持久化架構和模型的相對獨立性。
此外，還需要採用DAO模式來消弱應用的商務邏輯和資料庫訪問邏輯的關係，當使用持久化架構的時候，DAO模式可以把業務對象和持久化架構分開，當持久化機制發生改變時，這種改變不會對業務對象產生影響。
3.4. 控制器
控制器接受使用者的輸入並調用模型和視圖去完成使用者的需求。所以當單擊Web頁面中的超連結和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然後用確定用哪個視圖來顯示模型處理返回的資料。控制器負責統一控製程序流轉和計算，相當於CPU的功能。當用戶端發送操作請求後，由控制器接收請求並根據請求調用業務代理介面來完成請求，最後返回請求結果。
Struts 架構是一種位於MVC模式開發中扮演控制器角色的web架構應用。它位於程式的控制層，不負責具體實現商務邏輯，只負責建立和調用模型介面來實現商務邏輯的請求。Struts 架構可以做到統一控制流程程，在統一控制中又細分出單個事件的請求控制。
把控制層和視圖、模型層分開的好處是，無論是商務邏輯和視圖中的哪個組件發生改變，他們都只需要改變本身的那部分，而不需要設計其他的層次。
3.5. 視圖
視圖是使用者看到並與之互動的介面。對老式的Web應用程式來說，視圖就是由HTML元素組成的介面，在新式的Web應用程式中，HTML依舊在視圖中扮演著重要的角色。
如何處理應用程式的介面變得越來越有挑戰性。MVC一個大的好處是它能為你的應用程式處理很多不同的視圖。在視圖中其實沒有真正的處理髮生，不管這些資料是聯機儲存的還是一個僱員列表，作為視圖來講，它只是作為一種輸出資料並允許使用者操縱的方式。
Struts 架構也提供了視圖組件，基於Struts 的視圖 API，可以使程式開發速度提高，機構嚴禁，最重要的是可以把控制器和視圖完全分開，以消弱視圖中混合控制的機制，達到真正的模組獨立。
3.6. 總結
現在我們總結ＭVC的處理過程，首先控制器接收使用者的請求，並決定應該調用哪個模型來進行處理，然後模型用商務邏輯來處理使用者的請求並返回資料，最後控制器用相應的視圖格式化模型返回的資料，並通過展示層呈現給使用者。
四. 層次間關係
從視圖層到持久化層，他們只能調用在它下一層的介面，不允許跳躍式調用，從而使各層次間相對獨立，以達到增加重用、減少維護、修改工作量和模組化的目標。
五. 軟體項目開發流程圖
此處無法顯示
六. 應用實現技術
資訊層：Oracle
持久化層：自訂DAO架構、java EJB 實體Bean
業務對象：自訂class或第三方API，java EJB Session Bean
業務代理介面： interface
控制器： Struts Action
視圖： Struts taglib， 自訂taglib， JavaScript
七. 團隊
需求分析師：負責業務需求分析
系統構架師：負責系統構架每個模組
系統設計師：負責設計模組的業務對象和商務邏輯架構
軟體工程師：負責實現商務邏輯、控制器和視圖控制
介面設計時：負責介面設計
八. 開發模式
無論是軟體整體構架還是分模組構架，都必須有個明確的團隊分工合作，以下簡單說明模組開發中的流程
需求分析師 —— 進行商務邏輯分析，完成後交給系統構架師。
系統構架師 —— 在得到需求分析後，系統構架師根據需求首先進行設計概念性模型，在此步工作中，需要把業務對象細緻地抽象出來，並設計出整體模組的架構，完成後交給系統設計師。
系統設計師 —— 在擷取模組設計架構後，根據設計把概念性模型抽象成業務物件模型，並且需要根據需求設計出整個模組的商務邏輯架構和介面。完成後分別把邏輯架構和介面交給負責完成商務邏輯的軟體工程師和負責控制器視圖設計的軟體工程師。
各個軟體工程師在得到設計文檔後可以開始同步完成代碼編輯工作和視圖設計編程工作。
軟體工程師完後工作後把程式發布，交給測試工程師，測試工程師根據視圖完成測試案例編寫，並開始測試，完成後需要編寫測試報告。如果有BUG則退回軟體工程師，如果有商務邏輯改變，則有軟體工程師退回給系統設計師重新設計或改寫商務邏輯。無問題後由軟體工程師完成自己負責的模組使用者手冊。
至此，模組開發完畢，交付。
九. 參考文獻
本文參考以下文檔
a、CSDN中發表的技術文章
b、孫衛琴的《精通Struts：基於MVC的Java Web設計與開發 》
