一個app如果是一個人獨自開發，那麼你可以天馬行空的編寫代碼，因為是你一個人完成其功能需求，并且進行後期維護，但是這樣的app一般不存在，或者隻存在于畢業論文中。但是在公司中都是多個人或者多個業務組維護一個app，這就決定着app需要有一個好的架構，拆分出各個業務子產品，由不同的業務組維護自己的業務子產品。并且架構合理的app對于後期維護、UI變動以及app中某些子產品的複用提供了便利之處。
MVC作為經典的架構模式之一，雖然存在不足之處，但是很多app仍然使用該架構，那就說明MVC必有其存在的意義。
model--模型，統一管理各個對象模型，管理資料，有一定的複用性。
view--視圖，視圖的集合，用于展示控件，相關頁面
controller--控制器，view和model的粘合劑，view和model通過控制器彼此間接互動。
一、蘋果推薦的MVC模式
蘋果推薦的MVC模式如上圖，View和Model通過Controller協調。model通過通知機制通知Controller資料的變更，Controller更新View展示新的更新的資料；View接收使用者的操作，通過target-action等機制通知Controller，controller通過更新model來響應使用者的操作。一切都是如此的美好，但是事實卻非如此。
一般，初級開發者接觸到iOS開發後，經常将視圖處理的邏輯放在ViewController中視圖的生命周期函數中，沒有所謂的單獨的視圖檔案，将view和控制器合二為一了，使得控制器代碼量劇增。另外，随着業務的複雜性的提升， service 服務可能在大多時間無法快速滿足用戶端需要的資料需求，移動端愈發的要自行處理一部分邏輯計算操作。一慣的做法是在控制器中處理，最終導緻了控制器成了垃圾箱，越來越不可維護。導緻了臃腫的控制器的出現。，推薦的MVC模式就逐漸的變成下面的模式了。這就導緻了後期app維護的困難，編寫測試用例的困難程度。
但是，隻要我們在開發中合理的編寫代碼，合理的重構，MVC模式還是有很大的好處的，也不會導緻臃腫的控制器。
二、蘋果推獎的MVC模式詳細介紹
iOS中的MVC（Model-View-Controller）将軟體系統分為Model、View、Controller三部分

Model: 你的應app本質上是什麼，它能實作的功能是什麼，它持有資料。以登入業務來說，使用者對象即為模型。
Controller：處理Model和View之間的互動，通過view将Model中的資料展示給使用者；通過對model的更新來響應使用者在View上的操作
View：使用者可見的，一般是UIView的子類。用于UI控件的展示以及響應使用者的操作。
Controller可以直接通路Model，也可以直接控制View。
但Model和View不能互相通信。
Model和Controller
Model不能直接通路Controller，Controller可以直接通路Model
Model不能直接與Controller通訊，因為Model是獨立于UI存在的。但當Model發生改變想通知Controller時可使用廣播機制，在iOS中有NSNotification和KVO（Key-value observing）可供使用。
View和Controller之間的互動機制
view不能直接通路controller，controller可以直接通路view
（1）View向Controller發送消息使用Target—action機制，當使用者與app進行互動時，發生一些事件，比如滑動一個Slider（通過滑動Slider改變Label的值），滑動Slider後，對應的Slider的值就會改變，這時可能會給Lable重新指派，這時候就需要Controller來完成UI的邏輯，使用Target來向controller發消息，觸發action對應的方法
（2）有時候Controller需要實時監控View的狀态，這時Controller會通過protocol将其自身設為View的delegate，它讓View知道如果view想知道更多的資訊，就要向Controller發送delegate消息（即遵循某個協定），這樣當View will change、should change、did change 的時候Controller也會接到相應通知，做出相應的協調。
（3）View不存儲資料，view通過datasource向Controller發送消息（data？、count？at？），進而擷取Controller資料用來展示（Controller整理Model中的資料用于給View展示）。
推薦：唐巧大神的關于MVC的描述http://blog.devtang.com/2015/11/02/mvc-and-mvvm/