軟件體系結構【4】 MVC體系結構風格、分層風格

MVC是模型(Model)，視圖(View)和控制(Controller)的縮寫，是一種設計創建 Web 應用程序的模式。

最典型的MVC就是JSP + servlet + javabean的模式。

• Model（模型）表示應用程序核心功能與數據（比如數據庫記錄列表）。
• View（視圖）負責為用戶顯示信息（數據庫記錄）。一個模型可能擁有多個視圖。
• Controller（控制器）處理輸入（寫入數據庫記錄）。

• 模型的責任 
• 從數據庫取出數據，並且賦予數據變量
• 負責業務邏輯實現
• 負責數據驗證，然后將數據存入數據庫
• 視圖的責任
  • 獲取用戶輸入
    
  • 向controller發送處理請求
  • 接收來自Controller的反饋並將model的處理結果顯示給用戶

• 控制器的責任
• 接收來自客戶的請求
  
• 調用model業務邏輯方法
  
• 調用View顯示執行結果
  

MVC交互示意圖

對於數據更新，MVC采用改變-傳播機制(change-propagation)

• 如果用戶通過一個view的controller改變了model，所有的view必須反映出該改變。
• 當數據發生變化的時候，model通知所有的view，告訴他們數據已經改變了；
• Views可以遍歷model中的數據，以便發現到底是什么改變了。然后更新顯示數據。

使用觀察者模式的MVC架構類圖

使用MVC架構：

1）容易增加或者改變視圖。

事務邏輯被封裝在Model中，所以在新增加一個視圖的時候，不必要改動模型，而是因為業務邏輯都是一樣的，所以只需要新增加一個視圖類即可。

2) 容易獨立地更新每個獨立的軟件模塊

    由於一個應用被分離為三個軟件模塊，因此，我們可以獨立地改變其中的一個模塊，而不影響其它兩個模塊。例如，一個應用的業務流程或者業務規則的改變只需改動MVC的模型層。 

3)   代碼易開發易維護

4)   業務邏輯更易測試 

-不適合小型，中等規模的應用程序，花費大量時間將MVC應用到規模並不是很大的應用程序通常會得不償失；

-對於簡單的界面，嚴格遵循MVC，使模型、視圖與控制器分離，會增加結構的復雜性，並可能產生過多的更新操作，降低運行效率；

-視圖與控制器是相互分離，但卻是聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，反之亦然，這樣就妨礙了他們的獨立重用；

-依據模型操作接口的不同，視圖可能需要多次調用才能獲得足夠的顯示數據。對未變化數據的不必要的頻繁訪問，也將損害操作性能。

 

2、分層風格

分層系統采用多個層次組織，每一層必須起且僅起兩個作用：

（1）使用下層提供的功能。

（2）為上層提供服務。

最底層通常由硬件連接。

廣為人知的分層系統的應用是TCP/IP五層網絡模型、操作系統、數據庫系統等。

優點：

–支持逐層抽象的系統設計，有利於設計者對一個復雜系統進行分解；

–支持更新，因為每一層至多和相鄰的上下層交互，因此功能的改變通常只影響相鄰的上下層；

–支持復用，如果某獨立層保證了功能的完整性並且提供了文檔化的接口，便可在多個語境中復用。一組標准接口也可以使用各種不同的實現方法。

–支持測試。具有定義明確的層接口以及交換層接口的各個實現的能力提高了可測試性。

缺點：

§並不是每個系統都可以很容易地划分為分層的模式，甚至即使一個系統的邏輯結構是層次化的，出於對系統性能的考慮，系統設計師不得不把一些低級或高級的功能綜合起來；

§效率的降低：

–由分層風格構成的系統，運行效率往往低於整體結構。

–在上層中的服務如果有很多依賴於最底層，則相關的數據必須通過一些中間層的若干次轉化，才能傳到；

§很難找到合適的、正確的層次抽象方法：

–層數太少，分層不能完全發揮這種風格的可復用性、可更改性和可移植性上的潛力。

–層數過多，則引入不必要的復雜性和層間隔離冗余以及層間傳輸開銷。

–目前，沒有可行的廣為人們所認可的層粒度的確定和層任務的分配方法。

 

照舊一個栗子🌰。這里主要講解三層架構。

三層架構是近年來經常使用的軟件體系結構。該體系結構可以分為通用的3層架構與運行在互聯網上的三層架構軟件，這里說的是前者。

傳統的三層層次體系結構

顯示層(Presentation layer): 

• 顯示層通常包括用戶圖形界面，用於用戶輸入、用戶請求與顯示用戶請求的返回結果等。
• 顯示層調用應用層組件的過程，函數或者方法。但是應用層從來不會調用顯示層的功能。

應用層(Application layer)：或者稱為業務邏輯(Business Logic)層。主要包括應用的業務邏輯，實現了應用的商業功能。

• 該層的組件封裝了應用的核心數據與功能。
• 在該層中，如果要訪問數據庫或者要將程序運行中產生的數據存儲到數據庫，必須調用永久數據存儲層的相應的數據庫訪問方法，而不能直接訪問數據庫。

永久數據存儲層(Permanent Data Storage layer)：該層包含數據庫的訪問與將永久數據存儲到數據庫中的功能。

• 在Java實現中，該層包含了利用JDBC寫的數據庫訪問代碼。
• 該層不能調用應用層與顯示層，而只能將執行應用層的請求對數據庫的訪問結果返回給應用層。而應用層有可能將該數據返回給顯示層

 

 

3、三層層次架構與MVC軟件體系結構的比較

• 在形式上，三層架構類似於MVC 架構，都是由三部分軟件模塊組成的，但是實際上它們是不同的。

• 兩種架構相似之處如下：

1. 都是由三部分軟件模塊組成的
2. 三層架構的顯示層與MVC架構的View類似；
3. 三層架構的應用層與MVC架構的Model類似。

• 三層體系結構與MVC體系結構的區別如下：

1. 各個模塊之間的調用關系不同：
   • 三層架構的一個根本原則是顯示層不能直接越過應用層直接調用永久數據存儲層的代碼。首先顯示層必須調用應用層，然后再由應用層的相關的方法轉而調用永久數據存儲層。不允許有相反方向的調用。因此，三層架構的交互是線性的； 
   • MVC架構的程序組件之間的交互是三角形的：View對象發送更新給Controller對象，Controller對象更新Model對象，並且View對象直接地從Model對象得到更新。
2. 對數據庫的訪問方式不同：
• 三層架構指定一個永久數據訪問層，所有對數據庫的訪問均有此層承擔；
• MVC架構沒有指定專門的數據庫訪問模塊，一般的情況下是由Model直接訪問數據庫，但是也沒有排除Controller中直接訪問數據庫的可能。
3. 關於控制模塊的不同：
   • MVC架構中存在一個專門的Controller模塊；
   • 而層次架構中通常沒有這樣專門的模塊。事實上，很多設計者在層次架構中的應用層里面單獨地指定一個類似的控制模塊。

使用觀察者模式的3層層次架構與MVC架構

值得注意的是，在3層架構中，應用層與表示層之間使用觀察者模式必然會導致應用層對顯示層的調用(notifyObservers())，這違反了層次架構的原則。但是考慮到采用觀察者機制更新圖形界面的效率，以上的小小的“違規”也是值得的。