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

創(chuàng)新互聯(lián)公司專注于網(wǎng)站建設|網(wǎng)站維護|優(yōu)化|托管以及網(wǎng)絡推廣，積累了大量的網(wǎng)站設計與制作經(jīng)驗，為許多企業(yè)提供了網(wǎng)站定制設計服務，案例作品覆蓋石雕等行業(yè)。能根據(jù)企業(yè)所處的行業(yè)與銷售的產(chǎn)品，結(jié)合品牌形象的塑造，量身設計品質(zhì)網(wǎng)站。

1. MVC (Model-View-Controller)

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

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

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

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

2. MVP (Model-View-Presenter)

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

MVP 模式由于需要做大量的數(shù)據(jù)同步工作，Presenter 也會和 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，所以在實現(xiàn)時還是會有大量邏輯的堆砌，這常常被稱為“垃圾抽屜”。并且 ViewModel 通常也不能在多個 View 間重用。這時我們可以加入一個 Coordinator 來協(xié)調(diào) ViewModel 之間的跳轉(zhuǎn)，來提高其復用性。

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

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

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

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

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

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

網(wǎng)頁題目：一圖詳解五種前端架構(gòu)
URL標題：http://uogjgqi.cn/article/dposgpe.html