無論是 iOS 還是 Android 開發(fā)，前端架構(gòu)模式都是應(yīng)用程序開發(fā)中最常用的模式之一。開發(fā)人員引入這些模式是為了克服早期模式的局限性。那么，它們有什么不同呢？又解決了什么問題呢？

1. MVC (Model-View-Controller)

MVC 是最古老的模式，可追溯到近 50 年前。

• Model：封裝了數(shù)據(jù)以及對(duì)數(shù)據(jù)的操作。
• View：定義了數(shù)據(jù)的展示，并負(fù)責(zé)接收用戶輸入。
• Controller：定義了對(duì)用戶操作的響應(yīng)。作為 Model 和 View 的連接，處理用戶操作和數(shù)據(jù)上的改變。

MVC 模式的發(fā)明大大降低了前端數(shù)據(jù)和事件的管理難度。

MVC 模式的局限性在于所有事件都在 Controller 中處理，使得其比較臃腫。并且 View 和 Controller 的綁定過于緊密，不利于代碼復(fù)用。

2. MVP (Model-View-Presenter)

在 MVP 模式中，View 和 Model 不能直接通信，必須通過 Presenter 來更新數(shù)據(jù)。這樣，View 和 Model 就解耦了，可以作為單純的展示層而存在。

MVP 模式由于需要做大量的數(shù)據(jù)同步工作，Presenter 也會(huì)和 View 綁定過于緊密。

3. MVVM (Model-View-ViewModel)

MVVM 由微軟提出，用 ViewModel 的概念接管了 Presenter 的數(shù)據(jù)同步工作，這樣省去了很多在 Presenter 里面的模版代碼，架構(gòu)和代碼邏輯更加清晰。

4. MVVM-C (Model-View-ViewModel-Coordinator)

雖然 MVVM 省去了數(shù)據(jù)綁定的模版代碼，但其在架構(gòu)分層上只是用 ViewModel 取代了 Presenter，所以在實(shí)現(xiàn)時(shí)還是會(huì)有大量邏輯的堆砌，這常常被稱為“垃圾抽屜”。并且 ViewModel 通常也不能在多個(gè) View 間重用。這時(shí)我們可以加入一個(gè) Coordinator 來協(xié)調(diào) ViewModel 之間的跳轉(zhuǎn)，來提高其復(fù)用性。

5. VIPER (View-Interactor-Presenter-Entity-Router)

VIPER 架構(gòu)并不是基于 MVC 的改進(jìn)，它是全新的架構(gòu)模式，也是架構(gòu)職責(zé)劃分最明確的。然而其復(fù)雜度也是最大的，不適合較小規(guī)模的項(xiàng)目。

• View：定義了數(shù)據(jù)的展示，并負(fù)責(zé)接收用戶輸入。
• Entity：定義數(shù)據(jù)對(duì)象，但是不包括對(duì)數(shù)據(jù)訪問和操作。
• Interactor：負(fù)責(zé)從 Entity 獲取數(shù)據(jù)，執(zhí)行數(shù)據(jù)操作邏輯。這里的數(shù)據(jù)結(jié)構(gòu)獨(dú)立于界面顯示。
• Presenter：從 Interactor 獲取數(shù)據(jù)，展示給用戶。
• Router：負(fù)責(zé)模塊間的跳轉(zhuǎn)。

總體看來，每種模式都需要處理以下 3 個(gè)問題：

1. 數(shù)據(jù)源：一般從后端服務(wù)和存儲(chǔ)中獲得，其數(shù)據(jù)模型接近于后端。
2. 數(shù)據(jù)綁定：將一個(gè)或多個(gè)數(shù)據(jù)源整形處理為符合前端展示需要的數(shù)據(jù)，其數(shù)據(jù)模型可以一步到位接近前端模型，或者可以是一個(gè)中間狀態(tài)方便頁(yè)面間復(fù)用。
3. 事件響應(yīng)：響應(yīng)用戶的操作，并對(duì)數(shù)據(jù)進(jìn)行操作。

各個(gè)模式根據(jù)具體需求采用了不同的分層和解耦。我們需要根據(jù)需求來選取合適的架構(gòu)模式。