講這三種設計模式之前，咱先列舉一個使用場景，現在有如下需求：

開發需求：頁面有個列表用於顯示新聞，新聞可以收藏，點贊

L：負責承載新聞資料模型物件：標題，內容，等等

五：負責新聞展示的觀

C：負責新聞資料的業務邏輯和展示邏輯

不需要多說稍微有點經驗的人都知道程式碼該這麼寫在控制器裡面獲取資料，然後重新整理的tableView，顯示tableViewCell;細胞裡面包含展示資訊標題內容收藏按鈕點贊按鈕等等 命令+ R一跑，完美，開發完畢。

過了一段時間，產品要求在新聞列表裡面有的加上一些細胞其他UI，甚至有的UI跟之前的細胞完全不一樣，新聞資料模型也不斷變化，甚至新聞資料的獲取來源都分很多地方

其實一開始你用的確實是MVC，只是隨著需求的變更，慢慢的變成了MMM ...- C-VVV ......，本來按照MVC模式每個MV之間都有一個Ç層連線，可是寫著寫著ç層就莫名其妙的消失了。

誤區在哪呢？

1：也許是iOS版的控制器的UIViewController中的名字給人的錯覺，讓人以為控制器就一定是MVC中的C

2：MVC作為一種設計模式，他必須是業務分層的，也就是MVC只針對一個場景，男和V的變更，C也要適當跟著變更

所以在iOS的裡面控制器的責任是多變的，如果只有一個MVC場景，控制器作為Ç當仁不讓;可若是多個MVC場景，控制器只能作為一個業務場景，C這個東西你需要單獨建立一個NSObject，每一個MV都最好對於一個單獨的C；而控制器的作用很簡單，則是對這些多個的MVC進行配置，然後通知各個MVC模組的啟動，做好和自身業務強相關的東西。

總結下優點：MVC模式下，說控制器容易變的臃腫，其實只是可能你使用方法沒有到位;真正理解了，使用它的好處是很多的，MV的程式碼複用，容易拓展，可維護性。

缺點：MVC的架構並非完美，第一：過度的注重隔離，V這個東西一般都只對外暴露設定方法，當屬性多的時候，需要大量重複的設定方法（當然你可以採取執行時裡面的一些方法來設定屬性） 第二：業務邏輯和業務展示還是比較耦合的，比如一些V上面的點選事件都是在V層的，這個對於測試來說是不合理的，因為必須先生成V。

MVP

MVC的主要缺點在於業務邏輯和業務展示沒有區分，而MVP將業務邏輯和業務展示也做了一層隔離，M和V功能不變，原來的C只負責佈局，而所有的邏輯全部轉移到了P。

在上述例子中，可以把控制器當做Ç層，在Ç層建立各自的MVP，並繫結MVP的關係。相對於MVC它其實只做了一件事情，就是分割業務展示和業務邏輯，展示和邏輯分開後，只有能保證V在收到P的資料更新通知後能正常重新整理頁面，整個業務就不會有問題，因為V收到的通知其實都來自於P的資料獲取更新等操作，所以只要保證p層的這些操作都正常就行，測試的時候，也只是測試p層。

MVVM

MVP其實已經是很好的框架了，幾乎能解決目前所有問題，那為什麼還會出現MVVM呢？MVVM的基本使用套路是：M和V還是不變，增加一個VM層處理邏輯，但是三層之間的關係要變，V層引用VM，反過來不行，VM引用M，反過來不行。具體玩法是：在控制器裡面設定好三層的繫結關係，V引用VM，VM引用M，控制器裡面addView。疑問來了，VM處理完業務邏輯後改變M後如何更新V，一般來說都是通過KVO的機制。其實MVVM只是MVP的一個繫結進化方式，除去資料繫結方式，其他和MVP基本沒有區別，只是呈現方式不同而已。

最後作一個總結：這三個設計各有優勢，設計模式的選擇最終目的在於服務於人，注重架構注重分層都是為了開發效率。一切從實際出發，不要拘泥，不要古板。