以前做IOS開發工作的時候，部門領導苦口婆心的給我科普過MVC和MVVM的區別，簡要來說MVC框架臃腫，分工不明，只勝在程式碼量少。

MVVM程式碼量繁多、勝在框架分工明確便於除錯及應用。

當然那都是一倆年前對於當時剛入行作為菜雞的自己，對於這個框架的理解

現在重新來根據圖文講講來自三者的功能及區別。

並在在開始之前，先分別講述MVC、MVP、MVVM中的基本要素是什麼：

M = Models ：擁有資料、亦或者說是操作資料的資料展示層（DAL）*Data Access Layer；

V = Views ： 使用者的圖形介面展示層（GUI）*Graphical User Interface

C/P/VM = Controller/Prensenter/View Model：他們三者都代表著View與Model的中轉站或者說是粘合劑，一般來說用於處理使用者在View的操作對於Model的反饋。以及應對Model模型資料的變更，更新View上的圖形展示。

1.MVC

如圖所示，這是蘋果官方給出的MVC理想形式的MVC框架，模組功能劃分明確。

 整個流程大概是這樣的：

使用者點選當前視窗View的控制元件；將點選事件傳遞到控制器中；控制器處理完更新模型；模型通知控制器更新結束；控制器根據結果更新當前視窗View。

沒錯，熱心的同學已經看到了是 理 想

實際上的是怎麼樣的呢？  

如圖所示，這個才是現實中各位OSX開發者遇上的蘋果MVC框架上的真身。

還是從圖上來講，實際上APPLE的MVC中，V-C是捆綁在一起的，並且大多數情況View的作用僅僅是給Controller傳送action訊息。

並且，無論是理想還是現實中的MVC流程裡，Controller本身成為了所有東西的代理以及資料來源，包括髮送、取消網路請求、通知頁面、模型資料更改等。

是個過勞的傢伙。這意味著在這框架裡，ViewContorller成為功能的整合區。

口水話講，就是ViewController裡程式碼量是最多。

並且在現實中的MVC流程中，他們倆者（View、ViewController），在檢視中是互相牽扯

 我們來看看MVC中的特點

·職能劃分：

View / Model是互相分開

這意味著使用者與View的互動不會直接影響到模型（Model），必須要需要經過控制器（Controller）處理

View、ViewController緊密的連線在一起

上文有提到，因為這個緣故，View更多的時候只僅僅作為使用者action事件的傳送者，並不會成為功能的負擔者

·可測試性：

因為職能劃分的模糊，在頁面佈局沒有太大錯誤的時候，開發者自身更多測試的是自身的Model（業務邏輯、資料顯示）。

·易用性：

MVC的易用性是最高的，也同時是最簡單的。任何一個OSX開發者都是從MVC起步，這也意味著大多數開發者都對其熟悉，容易解讀。

並且程式碼量相當於其他框架而言是最少的。MVC的架構對小專案開發而言是最簡便的。

一句話總結：MVC架構的開發速度是最快的，對於小專案而言這是個最好的框架。

2. MVP

從圖片上來講，乍看下。MVP和MVC也差不多，但是實際上是如此嗎？流程也一樣？

並不是，MVP是能將職能精準劃分三塊的框架。這時候有人就會問了，他和MVC長得也差不多，為什麼MVC就不行呢？

別急別急，待我慢慢道來

MVP中加入了一個全新的模組Prensenter，用於取代Controller的位置作為中轉粘合劑，而原來的controller將和View一起被統一視作View。

還記得MVC中View和Controller的狀態嗎，是的他們緊密的聯絡在了一起。所以他們並不能做到分工明確，只能把所有事情讓controller扛著

所以MVP的框架模式中乾脆就讓他倆繼續繫結在一塊，讓Presenter來充當controller原來的角色處理業務。並且因為Presenter獨立在外的原因，所以Presenter本身與當前的ViewController中的生命週期並無關聯。

是一個真正的做到了Model作為資料訪問層，View作為圖形展示層，Presenter作為業務處理層三者互相獨立的框架模式。

那既然如此這個框架是不是特別完美沒有弊端呢？

也並不是，對於MVC而言，MVP框架確實有著模組分工明確，可測試性強等優點，但缺點也還是有的。

其1：View不太靈活

上文所述，因為Presenter本身與當前的ViewController中的生命週期並無關聯。這又是什麼意思呢？

因為Presenter沒有直接參與到檢視的生命週期中，所以Presenter中並沒有任何一句頁面佈局程式碼。但是在職能劃分中，他又有責任通過資料和狀態更新View。

所以在大多數情況下，MVP中的V僅僅作為佈局而存在。其也只在Presenter需要其更新的時候才會更新。

簡要點說，他是被動的。需要改變時改變，不需要改變時靜止。是不靈活的。

其2：程式碼量多

也因為MVP中的View是被動的。在初期開發中必須手動準備資料來源、繫結事件等。加重了開發的程式碼量。

那回過頭來， 我們來看看MVP中的特點：

·職能劃分：只能劃分明確，大部分的工作任務都劃分到Presenter和Model之中。View相對而言不太靈活。

·可測試性：可測試極強，大多數情況下可以通過View測試大部分業務邏輯。

·易用性：易用性佳，因為模組分工明確清晰，但程式碼開發程式碼量是MVC的倆倍有多。

一句話總結： 在開發中使用MVP意味著有著非常好的測試效能，以及非常多的程式碼編寫。（真實）

3.MVVM

這時候從讀者的角度出發，“從圖片中乍看一下，似乎和MVP也沒有太大區別？僅僅是一條線路變成雙向？emm又多了一個Binding欄位怎麼就變成了新框架了呢?"

是的，一開始我對於這框架也是這麼理解的，但是這個框架也得益於Binding（繫結）這個功能。

首先從圖片上來分析

他和MVP非常的像

· MVVM中，他把View和Controller也統一視作了View。

· View和Model沒有緊耦合。

那麼倆者的區別又是什麼呢？沒錯，Binding(繫結)

MVVM中，通過View Model與View的繫結，解決實現了資料與檢視同步的問題。

View Model 是View和View狀態獨立在UIKit外的一個呈現，View Model 通過呼叫Model中的變化，根據Model的變化進行調整，並通過View與View Model的繫結調整View。

簡單點講：當資料變動時，頁面會根據變動資料自動調整。是的沒錯，你是可以理解成智慧化調整。

至於繫結方法，如果我們不想寫一套程式碼出來的話，可以參考下

1、一個基於 KVO 的繫結框架，如：RZDataBinding或者SwiftBond

2、 使用全量級的函式式響應程式設計的框架，如ReactiveCocoa或者PromiseKit

具體選擇什麼框架，各取所需。

一的框架較為簡便，二的框架較為複雜。

MVVM的特點也是比較明顯的

·職能劃分：雖然MVVM與MVP的框架是相似的。但通過繫結機制，第一個View是由View Model更新狀態（繫結），第二個View只需要將事件傳遞到Presenter中執行就行，不需要更新狀態。會根據繫結View自行調整。

相比起MVP，MVVM中的View是主動的承擔了一部分職能，並不像MVP中View是完全被動的。

·可測試性：View Model中並不持有View，可以輕鬆的針對這個模組進行測試。View需要注意的是比較依賴於UIkit，但是也是可以方便模組測試的。

·易用性：易用性佳，雖然與MVP中相仿，但也因為繫結機制的存在，不用像MVP中需要用部分程式碼將事件傳遞到Presenter中，然後手動更新View那樣。程式碼量會減少不少。

一句話總結：結合現存框架的好處，也得益於繫結機制，可測試性大大提升。雖然程式碼量大，但整體來是最好的一套框架。 

結語：雖然非常簡單的瞭解了一下幾個框架之間的區別，但是針對不同的情況下，使用的框架也不一樣。不用分清楚誰優誰劣

比方說你用MVC框架構築了大部分系統原始碼，但是有一個模組用MVC框架無法很好的維護時，針對單一模組使用MVVM框架也是可行的。沒必要將框架全部推倒重來。

畢竟MVVM和MVC的相性也是絕佳的。MVP也是同理

那麼今天就到這裡結束啦~