MVC架構模式（2）

簡介：

       MVC最初是在Smaltalk_80中被用來構建用戶界面的。M表明模型Model，V表明視圖View，C表明控制器Controller。

       Model模型層，能夠簡單理解就是數據層，用於提供數據。在項目中，（簡單理解）通常把數據訪問和操做，好比將對象關係映射這樣的代碼做爲Model層，也就是對數據庫的操做這一些列的代碼做爲Model層。好比代碼中咱們會寫DAO類型的代碼，這個DAO能夠理解爲是屬於Model層的代碼。

       View視圖層，就是UI界面，功能是與用戶進行交互。通常全部的JSP、Html等頁面就是View層。

       Controller控制層，Controller層的功能就是將Model和View層進行關聯。好比View主要是顯示數據的，可是數據又須要Model去訪問，這樣的話，View會先告訴Controller，而後Controller再告訴Model，Model請求完數據以後，再告訴View。

 

      

 

　　MVC重要特色就是兩種分離：

　　視圖和數據模型的分離：使用不一樣的視圖對相同的數據進行展現；分離可視和不可視的組件，可以對模型進行獨立測試。由於分離了可視組件減小了外部依賴利於測試。（數據庫也是一種外部組件）

　　視圖和表現邏輯(Controller)的分離：Controller是一個表現邏輯的組件，並不是一個業務邏輯組件。MVC能夠做爲表現模式也能夠做爲建構模式，意味這Controller也能夠是業務邏輯。分離邏輯和具體展現，可以對邏輯進行獨立測試。

　　優勢：耦合性低；重用性高；生命週期成本低；部署塊；可維護性高；有利軟件工程化管理。

　　缺點：沒有明確的定義；不適合小型，中等規模的應用程序；增長系統結構和實現的複用性；視圖與控制器間的過於緊密的鏈接；視圖對模型數據的低效率訪問；通常高級的界面工具或構造器不支持模式。

 

適用場景：

       MVC 能夠說是最經典的架構模式，它適用於大部分的開發場景，若是對架構不怎麼了解，在MVC架構基礎上進行封裝與優化能夠知足絕大部分的需求

 

解決的問題：

       實現一種動態的程序設計，是後序對程序的修改和擴展簡化，而且使程序某一部分的重複利用稱爲可能。

　　經過對複雜度的簡化，使程序結構更加直觀。

　　將信息的內部表示與信息的呈現方式分離開來，並接受用戶的請求。它分離了組件，並容許有效的代碼重用。即，將模型和視圖的實現代碼分離，從而使同一個程序可使用不一樣的表現形式。好比一批統計數據你能夠分別用柱狀圖、餅圖來表示。C存在的目的則是確保模型和視圖的同步，一旦模型改變，視圖應該同步更新。

       增長代碼的重用率，減小數據表達、數據描述和應用操做的耦合度。同時也使得軟件可維護性、可修復性、可擴展性，靈活性以及封裝性大大提升

 

解決方案：

　　經過把職責、性質相近的成分歸結在一塊兒，不相近的進行隔離，MVC將系統分解爲模型、視圖、控制器三部分，每一部分都相對獨立，職責單一，在實現過程當中能夠專一於自身的核心邏輯。MVC是對系統複雜性的一種合理的梳理與切分，它的思想實質就是「關注點分離」。

 

實例：

       應用於基於MVC架構模式的框架，常見的服務器端MVC框架有：Struts、Spring MVC、ASP.NET MVC、Zend Framework、JSF；常見前端MVC框架：angularjs、reactjs、backbone；由MVC演化出了另一些模式如：MVP、MVVM。

       其實 Android 開發自己默認的就是一套 MVC 實現。

       View 層：Android 開發中的 xml 佈局就是咱們的 View 層，默認狀況下也建議 View 都儘可能用 xml 實現，固然對於一些複雜的就須要咱們自定義 View 了，自定義 View 一樣也是屬於 View 層，只不過大多數時候仍是 xml 佈局用的最多。

       Controller 層：毫無疑問，Android 默認也給咱們提供了 Controller，就是 Activity & Fragment，仔細想一想，是否是用戶的交互事件，如輸入、點擊、滑動等都是在 Activity、Fragment 中處理的？關於這點有人認爲 Activity & Fragment 屬於 View 層，這個我是不承認的，View 應該專一界面的顯示，Controller 處理用戶的交互，提供給 View 須要的數據，從而讓 View 正確的顯示出來，而這都是 Activity & Fragment 的工做。

       Model 層：Android 中對 View 與 Controller 有了定義，其實沒有對 Model 層作定義，而大部分架構都不會對 Model 層作定義，由於 Model 自己是跟業務相關，針對不一樣的業務模型，定義須要的數據模型與實體類，以及相關的業務邏輯處理，雖然 Android 沒有明肯定義 Model 層，可是咱們在開發中都會定義一個專門的 model  package 用來統一管理全部的 model 文件，如 User、Order、Chat 等。

       下面舉幾個簡單的例子：

　　例如①，小時候玩的那種卡帶式遊戲機，Control是主機，通常來講我買一個主機就好了，只要他不壞，他就能一直讓我玩這一類的遊戲。View則是電視機和遊戲手柄，電視機能夠獨立工做，他無論輸入的是電視信號、影碟機信號仍是遊戲機信號，他只管顯示，並且他決定了咱們看到的效果是怎麼樣的，若是我想要個尺寸更大的或者彩色的顯示效果，我只須要買個相應的電視機就好了，手柄也是能夠換的，遙杆仍是帶震動的。Model則是遊戲卡帶，他決定了我玩的是什麼遊戲，是魂鬥羅仍是超級瑪莉，並且遊戲機主機和電視機生產廠家永遠也不知道在上面有可能會運行什麼樣的遊戲。卡帶中可能會有遊戲代碼和存儲單元，都根據遊戲的須要而設計。

　　例如②，一個採用比例表示的用於政治選舉的一個簡單信息系統，它提供了一個輸入數據的電子數據表和表示當前結果的幾種圖標。用戶能夠經過圖形接口與系統交互。全部信息顯示必須當即反應出選舉數據的變化。（引用自《面向模式的軟件體系結構-卷1 模式系統》）

　　即，一旦模型的數據發生了變化，模型要通報全部的視圖。

 

MVC和三層架構的區別與聯繫：

       不少人都很容易把MVC和三層架構模式混淆，但其實二者有很大的區別。

       三層架構(3-tier application) 一般意義上的三層架構就是將整個業務應用劃分爲：

       表現層（UI）：展示給用戶的界面

       業務邏輯層（BLL）：針對具體問題的操做，也能夠說是對數據層的操做，對數據業務邏輯處理

       數據訪問層（DAL）：：該層所作事務直接操做數據庫，針對數據的增添、刪除、修改、更新、查找等

       嚴格來講MVC（Model-View-Controller）三個加起來之後纔是三層架構中的UI層，也就是說，MVC把三層架構中的UI層再度進行了分化，分紅了控制器、視圖、實體三個部分，控制器完成頁面邏輯，經過實體來與界面層完成通話；而C層直接與三層中的BLL進行對話。

 

　　MVC是表現層的架構，MVC的Model其實是ViewModel，即供View進行展現的數據。 ViewModel不包含業務邏輯，也不包含數據讀取。 而在N層架構中，通常還會有一個Model層，用來與數據庫的表相對應，也就是所謂ORM中的O。這個Model多是POCO，也多是包含一些驗證邏輯的實體類，通常也不包含數據讀取。進行數據讀取的是數據訪問層。而做爲UI層的MVC通常不直接操做數據訪問層，中間會有一個業務邏輯層封裝業務邏輯、調用數據訪問層。UI層（Controller）經過業務邏輯層來獲得數據（Model），並進行封裝（ViewModel），而後選擇相應的View