深入了解MV**模式
前言：做客戶端開發(fā)谭梗、前端開發(fā)坚芜，大致都應(yīng)該聽說過這么幾個名詞MVC、MVP来破、MVVM篮灼，這些架構(gòu)的思想大多是為了解決界面應(yīng)用程序復(fù)雜的邏輯問題。同時這些框架的核心目的在于徘禁，職責(zé)分離，不同的層次要做不同的事情髓堪。
無論是哪種MV**系列送朱，都涉及到了Model和View，如果單純的只有Model和View干旁，他們是沒有辦法一起協(xié)同工作的驶沼，所以就有了各種MV..的設(shè)計模式
MVXX模式：
- MVC
- MVP
- MVVM
這三種架構(gòu)模式都是現(xiàn)在比較流行的，在不同的項目中争群，可能采用不同的架構(gòu)模式回怜，今天我們就圍繞著這三種架構(gòu)模式的試用場景介紹一下他們的概念，以及異同换薄。
MVC
MVC(Model-View-Controller),Model:邏輯模型玉雾，View:視圖模型翔试，Controller控制器。簡單說這就是一種設(shè)計應(yīng)用程序的思想复旬，目的在于將業(yè)務(wù)邏輯垦缅、數(shù)據(jù)、界面分離驹碍，將業(yè)務(wù)邏輯聚集到一個部件里面壁涎，在改進或者想要定制界面及用戶交互時，不需要重寫編寫業(yè)務(wù)邏輯志秃。Controller和View都依賴Model層怔球，Controller和View相互依賴。
操作的過程：用戶在界面上進行操作(例如手機屏幕)浮还，這個時候View會捕捉到用戶的操作庞溜，然后將這個操作的處理權(quán)利交給Controller，Controller會對來自View的數(shù)據(jù)進行預(yù)處理碑定，決定調(diào)用哪個Model的接口流码，然后由Model執(zhí)行相應(yīng)的邏輯，當(dāng)Model變更之后延刘，再利用觀察者模式通知View漫试，View通過觀察者模式收到Model的消息之后，向Model請求最新的數(shù)據(jù)碘赖，然后更新頁面驾荣，如下圖：
看似沒有什么特別的地方，但是由幾個需要特別關(guān)注的關(guān)鍵點：
- View是把控制權(quán)交移給Controller普泡，Controller執(zhí)行應(yīng)用程序相關(guān)的應(yīng)用邏輯（對來自View數(shù)據(jù)進行預(yù)處理播掷、決定調(diào)用哪個Model的接口等等）。
- Controller操作Model撼班，Model執(zhí)行業(yè)務(wù)邏輯對數(shù)據(jù)進行處理歧匈。但不會直接操作View，可以說它是對View無知的砰嘁。
- View和Model的同步消息是通過觀察者模式進行件炉，而同步操作是由View自己請求Model的數(shù)據(jù)然后對視圖進行更新。
需要特別注意的是MVC模式的精髓在于第三點：Model的更新是通過觀察者模式告知View的矮湘，具體表現(xiàn)形式可以是Pub/Sub或者是觸發(fā)Events斟冕。而網(wǎng)上很多對于MVC的描述都沒有強調(diào)這一點。通過觀察者模式的好處就是：不同的MVC三角關(guān)系可能會有共同的Model缅阳，一個MVC三角中的Controller操作了Model以后磕蛇，兩個MVC三角的View都會接受到通知，然后更新自己。保持了依賴同一塊Model的不同View顯示數(shù)據(jù)的實時性和準(zhǔn)確性秀撇。我們每天都在用的觀察者模式超棺，在幾十年前就已經(jīng)被大神們整合到MVC的架構(gòu)當(dāng)中。
優(yōu)點
- 首先最重要的一點是多個視圖能共享一個模型捌袜，同一個模型可以被不同的視圖重用说搅，大大提高了代碼的可重用性。
- 由于MVC的三個模塊相互獨立虏等，在其中改變一個弄唧，其他兩個可以保持不變，這樣可以把耦合降得很低霍衫，這樣可以使開發(fā)人員可以只關(guān)注整個系統(tǒng)中的某一層
- 控制器提高了應(yīng)用程序的靈活性和可配置型候引。控制器可以用來連接不同的模型和視圖去完成用戶的需求敦跌，這樣控制器可以為構(gòu)造應(yīng)用程序提供強有力的手段
缺點
- 增加了系統(tǒng)結(jié)構(gòu)的實現(xiàn)的復(fù)雜性
- 視圖與控制器之間的聯(lián)系過于緊密澄干，視圖如果沒有控制器的存在，能夠做的事情少之又少柠傍，這樣視圖就很難獨立應(yīng)用了
- 視圖對模型的數(shù)據(jù)的訪問效率過低麸俘，因為之間需要多次的調(diào)用
- View無法組件化，View依賴于特定的Model惧笛，如果需要把這個View抽出來用在下一個應(yīng)用程序復(fù)用就比較困難了
MVP
Model(Model View Presenter),Model:邏輯模型从媚，View:視圖模型，Presenter:接口患整。
關(guān)于MVP的定義：
- MVC的演化版本拜效，讓Model和View完全解耦
- 代碼清晰，不過增加了很多類
MVP中的P各谚，是Presenter的含義紧憾，和MVC比較類似，都是將用戶對View的操作交付給Presenter昌渤，Presenter會執(zhí)行相應(yīng)的邏輯赴穗，在這過程中會操作Model，當(dāng)Model執(zhí)行完業(yè)務(wù)邏輯之后愈涩，同樣是通過觀察者模式把自己的結(jié)果傳遞出去望抽，不過不是告訴View，而是告訴Presenter履婉，Presenter得到消息后，通過View的接口更新頁面斟览。
在Android中毁腿，我們的View可能僅僅就是個布局文件，它能做的事情少之又少，真正與布局文件進行數(shù)據(jù)綁定操作的事Activity已烤，所以這樣做就使Activity即像View又像Controller鸠窗。
應(yīng)用了MVP之后：
- View:對應(yīng)Activity，負責(zé)View的繪制以及與用戶交互
- Model:業(yè)務(wù)邏輯和實體模型
- Presenter:負責(zé)完成View與Model之間的交互
應(yīng)用兩張圖來說明上述內(nèi)容:
MVP的優(yōu)點
- 便于測試胯究。Presenter對View是通過接口進行稍计，在對Presenter進行不依賴UI環(huán)境的單元測試的時候≡Ｑ可以通過Mock一個View對象臣嚣，這個對象只需要實現(xiàn)了View的接口即可。然后依賴注入到Presenter中剥哑，單元測試的時候就可以完整的測試Presenter應(yīng)用邏輯的正確性硅则。這里根據(jù)上面的例子給出了Presenter的單元測試樣例。
- View可以進行組件化株婴。在MVP當(dāng)中怎虫，View不依賴Model。這樣就可以讓View從特定的業(yè)務(wù)場景中脫離出來困介，可以說View可以做到對業(yè)務(wù)完全無知大审。它只需要提供一系列接口提供給上層操作。這樣就可以做到高度可復(fù)用的View組件座哩。
MVP的缺點
- 代碼量會一些徒扶，實現(xiàn)的難度也會增加一些
MVP與MVC區(qū)別
如下圖所示：
MVVM
MVVM是Model-View-ViewModel的簡寫，MVVM是思想上的一種變革八回，也可以看成是MVP的一種變革酷愧，它是將"數(shù)據(jù)模型數(shù)據(jù)雙向綁定"的思想作為核心，因此在View和Model之間便不需要我們寫聯(lián)系了缠诅，我們在修改數(shù)據(jù)的時候視圖就可以發(fā)生變化溶浴，我們在修改視圖的時候數(shù)據(jù)也是會發(fā)生變化的，可以在一定程度上提高我們的開發(fā)效率的管引。
調(diào)用關(guān)系
MVVM的調(diào)用關(guān)系和MVP一樣士败。但是，在ViewModel當(dāng)中會有一個叫Binder褥伴，或者是Data-binding engine的東西谅将。以前全部由Presenter負責(zé)的View和Model之間數(shù)據(jù)同步操作交由給Binder處理。你只需要在View的模版語法當(dāng)中重慢，指令式地聲明View上的顯示的內(nèi)容是和Model的哪一塊數(shù)據(jù)綁定的饥臂。當(dāng)ViewModel對進行Model更新的時候，Binder會自動把數(shù)據(jù)更新到View上去似踱，當(dāng)用戶對View進行操作（例如表單輸入）隅熙，Binder也會自動把數(shù)據(jù)更新到Model上去稽煤。這種方式稱為：Two-way data-binding，雙向數(shù)據(jù)綁定囚戚〗臀酰可以簡單而不恰當(dāng)?shù)乩斫鉃橐粋€模版引擎，但是會根據(jù)數(shù)據(jù)變更實時渲染驰坊。
也就是說匾二，MVVM把View和Model的同步邏輯自動化了。以前Presenter負責(zé)的View和Model同步不再手動地進行操作拳芙，而是交由框架所提供的Binder進行負責(zé)察藐。只需要告訴Binder，View顯示的數(shù)據(jù)對應(yīng)的是Model哪一部分即可态鳖。
Android官方推出的MVVM的DataBinding转培，便是一個雙向綁定的庫。
優(yōu)點
- 提高可維護性浆竭。解決了MVP大量的手動View和Model同步的問題浸须，提供雙向綁定機制。提高了代碼的可維護性邦泄。
- 簡化測試删窒。因為同步邏輯是交由Binder做的，View跟著Model同時變更顺囊，所以只需要保證Model的正確性肌索，View就正確。大大減少了對View同步更新的測試特碳。
缺點
- 過于簡單的圖形界面不適用诚亚，或說牛刀殺雞。
- 對于大型的圖形應(yīng)用程序午乓，視圖狀態(tài)較多站宗，ViewModel的構(gòu)建和維護的成本都會比較高。
- 數(shù)據(jù)綁定的聲明是指令式地寫在View的模版當(dāng)中的益愈，這些內(nèi)容是沒辦法去打斷點debug的梢灭。
