?在iOS開發(fā)過程中，MVC的使用可謂是眾所周知，作為iOS開發(fā)人員也都經(jīng)常使用這個模式。在MVC下，所有的對象都被歸類成一個Model、一個View、一個Controller。雖然現(xiàn)在MVC仍然是主流的框架，但是它也被慢慢的替換成MVVM，因為越來越多的開發(fā)人員調(diào)侃MVC為Massive View Controller。
一、MVVM
? ? ? ?MVVM是Model-View-ViewModel的簡寫。微軟的WPF帶來了新的技術(shù)體驗，如Silverlight、音頻、視頻、3D、動畫.....，這導(dǎo)致了軟件UI層更加細(xì)節(jié)化、可定制化。同時，在技術(shù)層面，WPF也帶來了諸如Binding、Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由來便是MVP（Model-View-Presenter）模式與WPF結(jié)合的應(yīng)用方式時發(fā)展演變過來的一種新型架構(gòu)框架。它立足于原有MVP框架并且把WPF的新特性糅合進去，以應(yīng)對客戶日益復(fù)雜的需求變化。
在這里我還是要推薦下我自己建的iOS開發(fā)學(xué)習(xí)群：680565220，群里都是學(xué)ios開發(fā)的，如果你正在學(xué)習(xí)ios ，小編歡迎你加入，今天分享的這個案例已經(jīng)上傳到群文件，大家都是軟件開發(fā)黨，不定期分享干貨（只有iOS軟件開發(fā)相關(guān)的），包括我自己整理的一份2018最新的iOS進階資料和高級開發(fā)教程
一種可以很好地解決Massive View Controller問題的辦法就是將Controller?中的展示邏輯抽取出來，放置到一個專門的地方，而這個地方就是ViewModel?。MVVM衍生于MVC，是對?MVC?的一種演進，它促進了UI代碼與業(yè)務(wù)邏輯的分離，而且正式規(guī)范了視圖和控制器緊耦合的性質(zhì)，并引入新的組件。
在MVVM中，View和View Controller是聯(lián)系在一起，可以把它們視為一個組件，View和View Controller都不能直接引用Model，而是通過引用視圖模型（ViewModel），ViewModel是一個放置用戶輸入驗證邏輯、視圖顯示邏輯、發(fā)起網(wǎng)絡(luò)請求和其他代碼的地方，使用MVVM會輕微的增加代碼量，但總體上減少了代碼的復(fù)雜性、耦合性。
二、MVVM設(shè)計模式模塊
由于WPF技術(shù)出現(xiàn)，使得MVP設(shè)計模式有所改進，MVVM模式便是使用的是數(shù)據(jù)綁定基礎(chǔ)架構(gòu)。它們可以輕松構(gòu)建UI的必要元素?？梢詤⒖糡he Composite Application Guidance for WPF(prism)，View綁定到ViewModel，然后執(zhí)行一些命令再向它請求一個動作。然而又反過來，ViewModel再跟Model通訊，告訴它更新來響應(yīng)UI。這樣便為應(yīng)用構(gòu)建UI非常的簡單容易。給一個應(yīng)用程序上貼一個界面越容易，外觀設(shè)計師就越容易使用Blend來創(chuàng)建一個漂亮的界面。同時，當(dāng)UI和功能越來越低耦合的時候，功能的可測試性就越來越強。
在MVP模式中，為了讓UI層能夠從邏輯層上分離下來，設(shè)計師們在UI層與邏輯層之間加了一層interface。無論是UI開發(fā)人員還是數(shù)據(jù)開發(fā)人員，都要尊重這個契約，按照它進行設(shè)計和開發(fā)。這樣，理想狀態(tài)下，無論是Web UI還是Window UI就都可以使用同一套數(shù)據(jù)邏輯了。借鑒MVP的IView層養(yǎng)成習(xí)慣，View Model聽起來比Presenter要貼切得多；會把一些跟事件、命令相關(guān)的東西放在MVC的'C',或者是MVVM的'VM’。
三、MVVM的優(yōu)缺點
（一）MVVM模式和MVC模式一樣，主要目的是分離視圖（View）和模型（Model），有幾大優(yōu)點：
1. 低耦合。視圖（View）可以獨立于Model變化和修改，一個ViewModel可以綁定到不同的"View"上，當(dāng)View變化的時候Model可以不變，當(dāng)Model變化的時候View也可以不變。
2. 可重用性。你可以把一些視圖邏輯放在一個ViewModel里面，讓很多view重用這段視圖邏輯。
3. 獨立開發(fā)。開發(fā)人員可以專注于業(yè)務(wù)邏輯和數(shù)據(jù)的開發(fā)（ViewModel），設(shè)計人員可以專注于頁面設(shè)計，使用Expression Blend可以很容易設(shè)計界面并生成xml代碼。
? ? ? ?4. 可測試。界面素來是比較難于測試的，而現(xiàn)在測試可以針對ViewModel來寫。
（二）MVVM模式的缺點：
1.數(shù)據(jù)綁定使得Bug很難被調(diào)試。如果界面發(fā)生錯誤，有可能是View的代碼有問題，也有可能是Model的代碼有問題。數(shù)據(jù)綁定使得一個位置的Bug被快速傳遞到別的位置，要想定位原始出問題的地方，就變得不那么容易了。
2.對于大型項目，數(shù)據(jù)綁定和數(shù)據(jù)轉(zhuǎn)化需要花費更多的內(nèi)存（成本）。主要在于：數(shù)組內(nèi)容的轉(zhuǎn)化成本較高：數(shù)組里面每項都要轉(zhuǎn)化成Item對象，如果Item對象中還有類似數(shù)組，就很頭疼。轉(zhuǎn)化之后的數(shù)據(jù)在大部分情況是不能直接被展示的，為了能夠被展示，還需二次轉(zhuǎn)化。只有在API返回的數(shù)據(jù)高度標(biāo)準(zhǔn)化時，這些對象原型（Item）的可復(fù)用程度才高，否則容易出現(xiàn)類型膨大，提高維護成本。
3.調(diào)試時通過對象原型查看數(shù)據(jù)內(nèi)容，不如直接通過NSDictionary或者NSArray這樣直觀。
4.同一API的數(shù)據(jù)被不同View展示時，難以控制數(shù)據(jù)轉(zhuǎn)化的代碼，它們有可能會散落在任何需要的地方。
四、MVVM模式的其他內(nèi)容
? ? ? ?1.使用MVVM來開發(fā)控件。由于控件在大部分情況下不涉及到數(shù)據(jù)的持久化，所以如果將M純粹理解為DomainModel的話，使用MVVM模式來進行自定義控件開發(fā)，實際上可以省略掉M，變成了VVM。
2.View可以引用ViewModel，但反過來不行（即：不要在ViewModel中引入#import UIKit.h，任何視圖本身的引用都不能放在ViewModel中），ViewModel可以引用Model，但反過來不行。
3.MVVM可以兼容當(dāng)前你使用的MVC架構(gòu)，也可以增加你開發(fā)的應(yīng)用的可測試性;MVVM配合一個綁定機制效果最好（eg:ReactiveCocoa）。
4.ViewController盡量不要涉及業(yè)務(wù)邏輯，讓ViewModel去做業(yè)務(wù)邏輯；ViewController 只是一個“中間人”，接收View的事件、調(diào)用ViewModel的方法、響應(yīng)ViewModel的變化；ViewModel 絕不能包含視圖View（UIKit.h），否則就跟View產(chǎn)生耦合，不方便復(fù)用和測試。
5.ViewModel之間可以有依賴；ViewModel要避免過于臃腫冗余，否則講重蹈Controller的覆轍，變得難以維護。
五、MVVM模式總則
MVC的設(shè)計模式也并非是必須摒棄的架構(gòu)，最低目前MVC設(shè)計模式仍是iOS開發(fā)的主流框架。MVVM是MVC的升級版，完全兼容當(dāng)前的MVC架構(gòu)，MVVM雖然促進了UI 代碼與業(yè)務(wù)邏輯的分離，一定程度上減輕了ViewController的耦合度，但是View和ViewModel之間的數(shù)據(jù)綁定，使得MVVM變得復(fù)雜和難用了，如果不能處理和駕馭二者間的數(shù)據(jù)綁定，仍然會造成Controller代碼過于復(fù)雜冗余、代碼邏輯不易維護的問題。
一個輕量級的ViewController是基于MVC和MVVM模式進行代碼職責(zé)的分離而打造的。MVC和MVVM優(yōu)缺點共存，但是優(yōu)點產(chǎn)生的效果遠(yuǎn)遠(yuǎn)蓋住了缺點的不良影響，它們的低耦合性、封裝性、可測試性、可維護性和多人協(xié)作便利等優(yōu)勢大大提高了開發(fā)效率。只要處理協(xié)調(diào)好二者之間的矛盾，就能很好的駕馭它們。
