再窺iOS架構模式

咱們爲何要在架構上費心思？

答案是：爲了減小在每作一個功能的時候所耗費的人力資源。

移動開發人員會在如下三個層面上評估一個架構的好壞：

1. 各個功能分區的職責分配是否均衡
2. 是否具備易測試性
3. 是否易於使用和維護

	職責分配的均衡性	易測試性	易用性
緊耦合MVC	❌	❌	✅
Cocoa MVC	❌ V和C是耦合的	❌	✅⭐
MVP	✅ 獨立的視圖生命週期	✅	通常：代碼較多
MVVM	✅	通常：視圖（View）存在對UIKit的依賴	通常
VIPER	✅⭐️	✅⭐️	❌

緊耦合MVC

舉一個例子，在一個多頁面的網頁Web應用程序中，當你點擊一個連接導航至其餘頁面的時候，該頁面就會被所有從新加載。該架構的問題在於視圖（View）與控制器（Controller）和模型（Model）是緊密耦合的。

Cocoa MVC

Cocoa MVC 是蘋果公司建議iOS開發者使用的架構。理論上來講，該架構能夠經過控制器（Controller）將模型（Model）與視圖（View）剝離開。

然而，在實際操做過程當中，Cocoa MVC 鼓勵大規模視圖控制器的使用，最終使得視圖控制器完成全部操做。

儘管測試這樣的耦合大規模視圖控制器是十分困難的，然而在開發速度方面，Cocoa MVC是現有的這些選擇裏面表現最好的。

MVP

在MVP中，Presenter與視圖控制器（view controller）的生命週期沒有任何關係，視圖能夠很輕易地被取代。咱們能夠認爲UIViewController實際上就是視圖（View）。

還有另一種類型的MVP：帶有數據綁定的MVP。以下圖所示，視圖（View）與模型（Model）和控制器（Controller）是緊密耦合的。

MVVM

MVVM與MVP類似不過MVVM綁定的是視圖（View）與視圖模型（View Model）。

VIPER

不一樣於MV(X)的三層結構，VIPER具備五層結構（VIPER View, Interactor, Presenter, Entity, 和 Routing）。這樣的結構能夠很好地進行職責分配可是其維護性較差。

相較於MV(X)，VIPER有下列不一樣點：

1. Model 的邏輯處理轉移到了 Interactor 上，這樣一來，Entities 沒有邏輯，只是純粹的保存數據的結構。
2. UI相關的業務邏輯分在Presenter中，數據修改功能分在Interactor中。
3. VIPER爲實現模塊間的跳轉功能引入了路由模塊 Router 。

本文首發於硅谷io