B/S構架MVC系統設計模式
阿新 • • 發佈：2019-01-17
一. 目的
提高程式碼重用、增加開發速度和減少維護修改量已經成為現軟體開發模式中日益提升的需求。框架、模型和介面也就隨此孕育而生。
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 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設計與開發 》
提高程式碼重用、增加開發速度和減少維護修改量已經成為現軟體開發模式中日益提升的需求。框架、模型和介面也就隨此孕育而生。
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 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設計與開發 》