一：mvc

mvc結構：

檢視（View）：使用者介面。
控制器（Controller）：業務邏輯
模型（Model）：資料儲存

mvc各部分的通訊方式

mvc互動模式

通過 View 接受指令，傳遞給 Controller。

另一種是直接通過controller接受指令。

mvc的歷史

MVC 的概念最早出現在二十世紀八十年代的 施樂帕克 實驗室中（對，就是那個發明圖形使用者介面和滑鼠的實驗室），當時施樂帕克為 Smalltalk 發明了這種軟體設計模式。

controller層的臃腫問題

於 View 來說，你如果抽象得好，那麼一個 App 的動畫效果可以很方便地移植到別的 App 上。
對於 Model 來說，它其實是用來儲存業務的資料的，如果做得好，它也可以方便地複用。
如果我們能夠意識到 Controller 裡面的程式碼不便於複用，我們就能知道什麼程式碼應該寫在 Controller 裡面了，那就是那些不能複用的程式碼。

一個解決的思路

Controller 裡面就只應該存放這些不能複用的程式碼，這些程式碼

在初始化時，構造相應的 View 和 Model。
監聽 Model 層的事件，將 Model 層的資料傳遞到 View 層。
監聽 View 層的事件，並且將 View 層的事件轉發到 Model 層。

Controller 只有以上的這些程式碼，那麼它的邏輯將非常簡單，而且也會非常短。

controller進一步的解決方案

但是，我們卻很難做到這一點，因為還是有很多邏輯我們不知道寫在哪裡，於是就都寫到了 Controller 中了，那我們接下來就看看其它邏輯應該寫在哪裡。

將 UITableView
 
 的 Data Source 分離到另外一個類中。
將資料獲取和轉換的邏輯分別到另外一個類中。
將拼裝控制元件的邏輯，分離到另外一個類中。

具體包括一下幾種解決方案：

• 將網路請求抽象到單獨的類中
• 將介面的拼裝抽象到專門的類中

• 構造 ViewModel
  這樣抽象之後，View 只接受 ViewModel，而 Controller 只需要傳遞 ViewModel 這麼一行程式碼。而另外構造 ViewModel 的過程，我們就可以移動到另外的類中了。

• 專門構造儲存類

二：MVP

MVP 模式將 Controller 改名為 Presenter，同時改變了通訊方向。

1. 各部分之間的通訊，都是雙向的。
2. View 與 Model 不發生聯絡，都通過 Presenter 傳遞。
3. View 非常薄，不部署任何業務邏輯，稱為”被動檢視”（Passive View），即沒有任何主動性，而 Presenter非常厚，所有邏輯都部署在那裡。

三：MVVM

MVVM 模式將 Presenter 改名為 ViewModel，基本上與 MVP 模式完全一致。

MVVM的歷史

相對於 MVC 的歷史來說，MVVM 是一個相當新的架構，MVVM 最早於 2005 年被微軟的 WPF 和 Silverlight 的架構師 John Gossman 提出，並且應用在微軟的軟體開發中。當時 MVC 已經被提出了 20 多年了，可見兩者出現的年代差別有多大。

MVVM的問題

MVVM 的作者 John Gossman 的 批評 應該是最為中肯的。John Gossman 對 MVVM 的批評主要有兩點：
第一點：資料繫結使得 Bug 很難被除錯。你看到介面異常了，有可能是你 View 的程式碼有 Bug，也可能是 Model 的程式碼有問題。資料繫結使得一個位置的 Bug 被快速傳遞到別的位置，要定位原始出問題的地方就變得不那麼容易了。
第二點：對於過大的專案，資料繫結需要花費更多的記憶體。

本篇文章是在讀唐巧和阮一峰的部落格後總結成的，許多地方直接複製貼上了（連結如下）