在iOS開發過程中，MVC的使用可謂是眾所周知，作為iOS開發人員也都經常使用這個模式。在MVC下，所有的物件都被歸類成一個Model、一個View、一個Controller。雖然現在MVC仍然是主流的框架，但是它也被慢慢的替換成MVVM，因為越來越多的開發人員調侃MVC為Massive View Controller。

一、MVVM

       MVVM是Model-View-ViewModel的簡寫。微軟的WPF帶來了新的技術體驗，如Silverlight、音訊、視訊、3D、動畫.....，這導致了軟體UI層更加細節化、可定製化。同時，在技術層面，WPF也帶來了諸如Binding、

Dependency Property、Routed Events、Command、DataTemplate、ControlTemplate等新特性。MVVM（Model-View-ViewModel）框架的由來便是MVP（Model-View-Presenter）模式與WPF結合的應用方式時發展演變過來的一種新型架構框架。它立足於原有MVP框架並且把WPF的新特性糅合進去，以應對客戶日益複雜的需求變化。 

       一種可以很好地解決Massive View Controller問題的辦法就是將Controller 中的展示邏輯抽取出來，放置到一個專門的地方，而這個地方就是ViewModel 。MVVM衍生於MVC，是對 MVC 的一種演進，它促進了UI程式碼與業務邏輯的分離，而且正式規範了檢視和控制器緊耦合的性質，並引入新的元件。

       在MVVM中，View和View Controller是聯絡在一起，可以把它們視為一個元件，View和View Controller都不能直接引用Model，而是通過引用檢視模型（ViewModel），ViewModel是一個放置使用者輸入驗證邏輯、檢視顯示邏輯、發起網路請求和其他程式碼的地方，使用MVVM會輕微的增加程式碼量，但總體上減少了程式碼的複雜性、耦合性。

二、MVVM設計模式模組

       由於WPF技術出現，使得MVP設計模式有所改進，MVVM模式便是使用的是資料繫結基礎架構。它們可以輕鬆構建UI的必要元素。可以參考The Composite Application Guidance for WPF(prism)，View繫結到ViewModel，然後執行一些命令再向它請求一個動作。然而又反過來，ViewModel再跟Model通訊，告訴它更新來響應UI。這樣便為應用構建UI非常的簡單容易。給一個應用程式上貼一個介面越容易，外觀設計師就越容易使用Blend來建立一個漂亮的介面。同時，當UI和功能越來越低耦合的時候，功能的可測試性就越來越強。
       在MVP模式中，為了讓UI層能夠從邏輯層上分離下來，設計師們在UI層與邏輯層之間加了一層interface。無論是UI開發人員還是資料開發人員，都要尊重這個契約，按照它進行設計和開發。這樣，理想狀態下，無論是Web UI還是Window UI就都可以使用同一套資料邏輯了。借鑑MVP的IView層養成習慣，View Model聽起來比Presenter要貼切得多；會把一些跟事件、命令相關的東西放在MVC的'C',或者是MVVM的'VM’。

三、MVVM的優缺點

       （一）MVVM模式和MVC模式一樣，主要目的是分離檢視（View）和模型（Model），有幾大優點：

       1. 低耦合。檢視（View）可以獨立於Model變化和修改，一個ViewModel可以繫結到不同的"View"上，當View變化的時候Model可以不變，當Model變化的時候View也可以不變。
       2. 可重用性。你可以把一些檢視邏輯放在一個ViewModel裡面，讓很多view重用這段檢視邏輯。
       3. 獨立開發。開發人員可以專注於業務邏輯和資料的開發（ViewModel），設計人員可以專注於頁面設計，使用Expression Blend可以很容易設計介面並生成xml程式碼。

       4. 可測試。介面素來是比較難於測試的，而現在測試可以針對ViewModel來寫。

       （二）MVVM模式的缺點：

1.資料繫結使得Bug很難被除錯。如果介面發生錯誤，有可能是View的程式碼有問題，也有可能是Model的程式碼有問題。資料繫結使得一個位置的Bug被快速傳遞到別的位置，要想定位原始出問題的地方，就變得不那麼容易了。
2.對於大型專案，資料繫結和資料轉化需要花費更多的記憶體（成本）。主要在於：陣列內容的轉化成本較高：數組裡面每項都要轉化成Item物件，如果Item物件中還有類似陣列，就很頭疼。轉化之後的資料在大部分情況是不能直接被展示的，為了能夠被展示，還需二次轉化。只有在API返回的資料高度標準化時，這些物件原型（Item）的可複用程度才高，否則容易出現型別膨大，提高維護成本。

3.除錯時通過物件原型檢視資料內容，不如直接通過NSDictionary或者NSArray這樣直觀。
4.同一API的資料被不同View展示時，難以控制資料轉化的程式碼，它們有可能會散落在任何需要的地方。

四、MVVM模式的其他內容

       1.使用MVVM來開發控制元件。由於控制元件在大部分情況下不涉及到資料的持久化，所以如果將M純粹理解為DomainModel的話，使用MVVM模式來進行自定義控制元件開發，實際上可以省略掉M，變成了VVM。

       2.View可以引用ViewModel，但反過來不行（即：不要在ViewModel中引入#import UIKit.h，任何檢視本身的引用都不能放在ViewModel中），ViewModel可以引用Model，但反過來不行。

       3.MVVM可以相容當前你使用的MVC架構，也可以增加你開發的應用的可測試性;MVVM配合一個繫結機制效果最好（eg:ReactiveCocoa）。
       4.ViewController儘量不要涉及業務邏輯，讓ViewModel去做業務邏輯；ViewController 只是一個“中間人”，接收View的事件、呼叫ViewModel的方法、響應ViewModel的變化；ViewModel 絕不能包含檢視View（UIKit.h），否則就跟View產生耦合，不方便複用和測試。
       5.ViewModel之間可以有依賴；ViewModel要避免過於臃腫冗餘，否則講重蹈Controller的覆轍，變得難以維護。

五、MVVM模式總則

       MVC的設計模式也並非是必須摒棄的架構，最低目前MVC設計模式仍是iOS開發的主流框架。MVVM是MVC的升級版，完全相容當前的MVC架構，MVVM雖然促進了UI 程式碼與業務邏輯的分離，一定程度上減輕了ViewController的耦合度，但是View和ViewModel之間的資料繫結，使得MVVM變得複雜和難用了，如果不能處理和駕馭二者間的資料繫結，仍然會造成Controller程式碼過於複雜冗餘、程式碼邏輯不易維護的問題。
       一個輕量級的ViewController是基於MVC和MVVM模式進行程式碼職責的分離而打造的。MVC和MVVM優缺點共存，但是優點產生的效果遠遠蓋住了缺點的不良影響，它們的低耦合性、封裝性、可測試性、可維護性和多人協作便利等優勢大大提高了開發效率。只要處理協調好二者之間的矛盾，就能很好的駕馭它們。

歡迎關注三掌櫃的微信公眾號，有更多精彩內容等著您來！