2.講一下MVC和MVVM，MVP

關於專案架構方面的面試題幾乎在每次面試中都會提到，架構方式有很多種，從最開始的MVC模式，演化到MVP，然後到現在的MVVM模式，在不斷的演化過程中核心思想歸根結底還是降低各元件之間的耦合度，使得資料的流向更加清晰明瞭。演化的過程並不意味著新的模式比以前的模式更加高階，只是對於專案的不同場景有了更多的選擇方案。下面就針對這三種比較常用的設計模式進行簡單的分析和對比，僅供參考。

MVC（Model、View、Controller）

MVC是比較直觀的架構模式，最核心的就是通過Controller層來進行調控，首先看一下官方提供的MVC示意圖：

• Model和View永遠不能相互通訊，只能通過Controller傳遞

• Controller可以直接與Model對話（讀寫呼叫Model），Model通過NOtification和KVO機制與Controller間接通訊

Controller可以直接與View對話，通過IBoutlet直接操作View，IBoutlet直接對應View的控制元件（例如建立一個Button：需宣告一個 IBOutlet UIButton * btn），View通過action向Controller報告時間的發生(使用者點選了按鈕)。Controller是View的直接資料源

優缺點

• 優點：對於混亂的專案組織方式，有了一個明確的組織方式。通過Controller來掌控全域性，同時將View展示和Model的變化分開

• 缺點：愈發笨重的Controller，隨著業務邏輯的增加，大量的程式碼放進Controller，導致Controller越來越臃腫，堆積成千上萬行程式碼，後期維護起來費時費力

MVP（Model、View、Presenter）

MVP模式是MVC模式的一個演化版本，其中Model與MVC模式中Model層沒有太大區別，主要提供資料儲存功能，一般都是用來封裝網路獲取的json資料；View與MVC中的View層有一些差別，MVP中的View層可以是viewController、view等控制元件；Presenter層則是作為Model和View的中介，從Model層獲取資料之後傳給View。

從上圖可以看出，從MVC模式中增加了Presenter層，將UIViewController中複雜的業務邏輯、網路請求等剝離出來。

• 優點 模型和檢視完全分離，可以做到修改檢視而不影響模型；更高效的使用模型，View不依賴Model，可以說VIew能做到對業務邏輯完全分離

• 缺點 Presenter中除了處理業務邏輯以外，還要處理View-Model兩層的協調，也會導致Presenter層的臃腫

MVVM（Model、Controller/View、ViewModel）

在MVVM中，view和ViewCOntroller聯絡在一起，我們把它們視為一個元件，view和ViewController都不能直接引用model，而是引用是檢視模型即ViewModel。

viewModel是一個用來放置使用者輸入驗證邏輯、檢視顯示邏輯、網路請求等業務邏輯的地方，這樣的設計模式，會輕微增加程式碼量，但是會減少程式碼的複雜性

• 優點 VIew可以獨立於Model的變化和修改，一個ViewModel可以繫結到不同的View上，降低耦合，增加重用

• 缺點 過於簡單的專案不適用、大型的專案檢視狀態較多時構建和維護成本太大

合理的運用架構模式有利於專案、團隊開發工作，但是到底選擇哪個設計模式，哪種設計模式更好，就像本文開頭所說，不同的設計模式，只是讓不同的場景有了更多的選擇方案。根據專案場景和開發需求，選擇最合適的解決方案。

對於設計模式的理解，就像一千個人眼裡就有一千個哈姆雷特一樣，以上觀點僅供參考，如有差錯，歡迎指正。