首先，1.MVC，全稱是：Model View Controller ，是模型、視圖、控制器。是一種常見的客戶端軟件開發(fā)框架

在ios開發(fā)中，系統(tǒng)為我們實現(xiàn)好了公共的視圖類：UIView,控制器：UIViewController。大多數(shù)時候我們都需要集成這些類實現(xiàn)程序邏輯；MVC 這種分層方式雖然清楚，但是如果使用不當，很可能讓大量代碼都集中在 Controller 之中，讓 MVC 模式變成了 Massive View Controller 模式。

Controller的臃腫問題

? ? ? 其實設計模式喝多時候是為了Don't repeat yourself 原則來做的，該原則要求能夠重復的代碼要金狼服用，來保證重用。在MVC這種設計模式中，我們發(fā)現(xiàn)View和model都是符合這種原則

? ? ? 對于View來說，視圖僅僅是展示給用的界面視圖，一個視圖的展示，我們來單獨封裝一個類，向外邊提供接口，供Controller使用

? ? ?對于Model，把不規(guī)則的數(shù)據(jù)源，進過model 統(tǒng)一處理成規(guī)則的model，什么空字符，null，都要在model中處理

? ? Controller，這種很少可以復用，我們可能可以用addSubViewController之類的方式復用 Controller，但它的復用場景還是非常非常少的。

如果我們能夠意識到 Controller 里面的代碼不便于復用，我們就能知道什么代碼應該寫在 Controller 里面了，那就是那些不能復用的代碼。在我看來，Controller 里面就只應該存放這些不能復用的代碼，這些代碼包括：

在初始化時，構造相應的 View 和 Model。

監(jiān)聽 Model 層的事件，將 Model 層的數(shù)據(jù)傳遞到 View 層。

監(jiān)聽 View 層的事件，并且將 View 層的事件轉(zhuǎn)發(fā)到 Model 層。

如果 Controller 只有以上的這些代碼，那么它的邏輯將非常簡單，而且也會非常短。

但是，我們卻很難做到這一點，因為還是有很多邏輯我們不知道寫在哪里，于是就都寫到了 Controller 中了，那我們接下來就看看其它邏輯應該寫在哪里。但是但是，我突然想到，我們好象只需要一個 ViewModel 而已，我完全可以簡單地做一個 ViewModel 的工廠類或 Service 類就可以了，為什么要引入這么多框架？現(xiàn)有的 MVC 真的有那么大的問題嗎？

MVVM 的作用和問題

MVVM是 Model-View-ViewModel 的簡寫。

相對于 MVC 的歷史來說，MVVM 是一個相當新的架構，MVVM 最早于 2005 年被微軟的 WPF 和 Silverlight

的架構師 John Gossman 提出，并且應用在微軟的軟件開發(fā)中。當時 MVC 已經(jīng)被提出了 20 多年了，可見兩者出現(xiàn)的年代差別有多大。

MVVM 在使用當中，通常還會利用雙向綁定技術，使得 Model 變化時，ViewModel 會自動更新，而 ViewModel 變化時，View 也會自動變化。所以，MVVM 模式有些時候又被稱作：model-view-binder模式。

具體在 iOS 中，可以使用 KVO 或 Notification 技術達到這種效果。

MVVM 在實際使用中，確實能夠使得 Model 層和 View 層解耦，但是如果你需要實現(xiàn) MVVM 中的雙向綁定的話，那么通常就需要引入更多復雜的框架來實現(xiàn)了。

對此，MVVM 的作者 John Gossman 的批評應該是最為中肯的。John Gossman 對 MVVM 的批評主要有兩點：

第一點：數(shù)據(jù)綁定使得 Bug 很難被調(diào)試。你看到界面異常了，有可能是你 View 的代碼有 Bug，也可能是 Model 的代碼有問題。數(shù)據(jù)綁定使得一個位置的 Bug 被快速傳遞到別的位置，要定位原始出問題的地方就變得不那么容易了。

第二點：對于過大的項目，數(shù)據(jù)綁定需要花費更多的內(nèi)存。

某種意義上來說，我認為就是數(shù)據(jù)綁定使得 MVVM 變得復雜和難用了。但是，這個缺點同時也被很多人認為是優(yōu)點。