iOS架構設計：揭祕MVC, MVP, MVVM以及VIPER

不要錯過最新的iOS開發技能樹 —— github地址

更新：在這裏可以看到幻燈片
在iOS中使用MVC時感覺怪怪的？對切換到MVVM有疑慮？聽說過VIPER，但不知道是否值得？

往下看，你將會找到這些問題的答案，如果還有疑問，請在評論區留言。

你將瞭解到在iOS環境下如何進行系統架構設計。我們將簡單回顧一些流行的框架，並通過實踐一些小例子來比較它們的理論。如果需要更多詳細信息，請參考文章中出現的鏈接。

掌握設計模式可能會讓人上癮，所以要小心：你可能在閱讀這篇文章之前已經問過自己一些問題，比如說：
誰應該擁有聯網請求：Model還是Controller？
如何將Model傳遞到新View的View Model中？
誰創建了一個新的VIPER模塊：Router還是Presenter？

爲什麼要糾結選擇什麼架構呢？

假如有一天，你在調試一個實現了幾十種功能的龐大的類時，你會發現自己很難找到並修復你的類中的任何錯誤。並且，很難把這個類作爲一個整體來考慮，因此，你總會忽略一些重要的細節。如果你的應用程序中已經出現了這種情況，那麼很有可能：

這類是UIViewController類。
UIViewController直接存儲和處理你的數據
你的UIView中幾乎沒有做任何事情
Model僅僅是一個數據結構
單元測試覆蓋不了任何內容

即使你遵循了蘋果的指導方針並實現了蘋果的MVC模式，這種情況還是會發生的，所以不要難過。蘋果的MVC有點問題，這個我們稍後再談。

讓我們定義一個優秀系統結構的特徵：
1.角色間職責的清晰分配（分佈式）。
2.可測試性通常來自第一個特性（不必擔心：使用適當的系統結構是很容易的）。
3.使用方便，維護成本低。

爲什麼要採用分佈式

當我們想弄清楚某些事情是如何運作時，採用分佈式能讓我們的大腦思路清晰。如果你認爲你開發越多，你的大腦就越能理解複雜性，那麼你是對的。但這種能力不是線性的，很快就會達到上限。因此，克服複雜性的最簡單方法是按照單一職責原則在多個實體之間劃分職責。

爲什麼要可測試

對於那些已經習慣了單元測試的人來說，這通常不是問題，因爲在添加了新的特性或者要增加一些類的複雜性之後通常會失敗。這意味着測試能夠降低應用程序在用戶的設備上發生問題的概率，那時修復也許需要一個星期（審覈）才能到達用戶。

爲什麼要易用性

這並不需要回答，但值得一提的是，最好的代碼是從未編寫過的代碼。因此，你擁有的代碼越少，你擁有的bug就越少。這意味着編寫更少代碼的願望決不能僅僅由開發人員的懶惰來解釋，你不應該偏愛看起來更聰明的解決方案而忽視它的維護成本。

MV(X) 簡介

現在我們在架構設計模式上有很多選擇：

他們中的三個假設將應用程序的實體分成3類：

Models — 負責保存數據或數據訪問層，操縱數據，例如“人”或“提供數據的人”。
Views — 負責表示層（GUI），iOS環境下通常以“UI”前綴。
Controller/Presenter/ViewModel — Model和View之間的中介，一般負責在用戶操作View時更新Model，以及當Model變化時更新View。

這種劃分能讓我們：

更好地理解它們（如我們所知）
重用它們（尤其是View和Model）
獨立地進行測試（單元測試）

讓我們從MV(X)開始，稍後在回到VIPER：

MVC

曾經

在討論蘋果對MVC的看法之前，讓我們先看看傳統的MVC。

在上圖的情況下，View是無狀態的。一旦Model被改變，Controller就會簡單地渲染它。例如：網頁完全加載後，一旦你按下鏈接，就導航到其他地方。
雖然在iOS應用用傳統的MVC架構也可以實現，但這並沒有多大意義，由於架構問題 ——三個實體是緊耦合的，每個實體和其他兩個通信。這大大降低了可重用性——這可不是你希望在你的應用程序看到的。出於這個原因，我們甚至不想編寫規範的MVC示例。

傳統的MVC似乎不適用於現代IOS開發。

蘋果的MVC

願景：

Controller是View和Model之間的中介，這樣他們就解耦了。最小的可重用單元是Controller，這對我們來說是個好消息，因爲我們必須有一個來放那些不適合放入Model的複雜業務邏輯的地方。
從理論上講，它看起來很簡單，但你覺得有些地方不對，對吧？你甚至聽到有人說MVC全稱應該改爲Massive View Controller（大量的視圖控制器）。此外，爲View controller減負也成爲iOS開發者面臨的一個重要話題。
如果蘋果只接受傳統的MVC並改進了它，爲什麼會出現這種情況呢？

實際情況：

Cocoa MVC鼓勵人們編寫大規模的視圖控制器，而且由於它們涉及View的生命週期，所以很難說它們（View和Controller）是分離的。
雖然你仍有能力將一些業務邏輯和數據轉換成Model，但你沒辦法將View從Controller中分離。在大多數時候所有View的責任是把事件傳遞給Controller。
ViewController最終演變成一個其他人的delegate和data source，通常負責分派和取消網絡請求…你明白的。
你見過多少這樣的代碼？：

var userCell = tableView.dequeueReusableCellWithIdentifier("identifier") as UserCell
userCell.configureWithUser(user)

Cell(一個View)跟一個Model直接綁定了！所以MVC準則被違反了，但是這種情況總是發生，通常人們不會覺得它是錯誤的。如果你嚴格遵循MVC，那麼你應該從Controller配置cell，而不是將Model傳遞到cell中，這將增大Controller。

Cocoa MVC 的全稱應該是 Massive View Controller.

在單元測試之前，這個問題可能並不明顯（希望在你的項目中是這樣）。
由於視圖控制器與視圖緊密耦合，因此很難測試——因爲在編寫視圖控制器的代碼時，你必須模擬View的生命週期，從而使你的業務邏輯儘可能地與View層的代碼分隔開來。
讓我們看一看簡單的操場例子：

import UIKit

struct Person { // Model
    let firstName: String
    let lastName: String
}

class GreetingViewController : UIViewController { // View + Controller
    var person: Person!
    let showGreetingButton = UIButton()
    let greetingLabel = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        self.showGreetingButton.addTarget(self, action: "didTapButton:", forControlEvents: .TouchUpInside)
    }

    func didTapButton(button: UIButton) {
        let greeting = "Hello" + " " + self.person.firstName + " " + self.person.lastName
        self.greetingLabel.text = greeting

    }
    // 這裏寫佈局代碼
}
// 組裝MVC
let model = Person(firstName: "David", lastName: "Blaine")
let view = GreetingViewController()
view.person = model;

MVC在可見的ViewController中進行組裝

這似乎不太容易測試，對嗎？
我們可以將greeting移動到新的GreetingModel類中並分別進行測試，但我們不能在不調用GreetingViewController的有關方法(viewDidLoad, didTapButton，這將會加載所有的View) 的情況下測試UIView中的顯示邏輯（雖然在上面的例子中沒有太多這樣的邏輯）。這不利於單元測試。
事實上，在一個模擬器（如iPhone 4S）中測試UIViews並不能保證它會在其他設備良好的工作（例如iPad），所以我建議從你的單元測試Target中刪除“Host Application”選項，然後脫離應用程序運行你的測試。

View和Controller之間的交互在單元測試中是不可測試的。

如此看來，Cocoa MVC 模式似乎是一個很糟糕的選擇。但是讓我們根據文章開頭定義的特性來評估它：

職責拆分 — View和Model實現了分離，但是View與Controller仍是緊耦合。
可測性 — 由於模式的原因，你只能測試你的Model。
易用性 — 相比於其他模式代碼量最少。此外，每個人都熟悉它，即使經驗不太豐富的開發人員也能夠維護它。

如果你不願意在項目的架構上投入太多的時間，那麼Cocoa MVC 就是你應該選擇的模式。而且你會發現用其他維護成本較高的模式開發小的應用是一個致命的錯誤。

Cocoa MVC是開發速度最快的架構模式。

MVP

MVP 實現了Cocoa的MVC的願景

這看起來不正是蘋果的MVC嗎？是的，它的名字是MVP（Passive View variant，被動視圖變體）。等等...這是不是意味着蘋果的MVC實際上是MVP？不，不是這樣。如果你仔細回憶一下，View是和Controller緊密耦合的，但是MVP的中介Presenter並沒有對ViewController的生命週期做任何改變，因此View可以很容易的被模擬出來。在Presenter中根本沒有和佈局有關的代碼，但是它卻負責更新View的數據和狀態。

假如告訴你,UIViewController就是View呢？

在MVP中，UIViewController的子類實際上是Views而不是Presenters。這種模式的可測試性得到了極大的提高，付出的代價是開發速度的一些降低，因爲必須要做一些手動的數據和事件綁定，從下例中可以看出：

import UIKit

struct Person { // Model
    let firstName: String
    let lastName: String
}

protocol GreetingView: class {
    func setGreeting(greeting: String)
}

protocol GreetingViewPresenter {
    init(view: GreetingView, person: Person)
    func showGreeting()
}

class GreetingPresenter : GreetingViewPresenter {
    unowned let view: GreetingView
    let person: Person
    required init(view: GreetingView, person: Person) {
        self.view = view
        self.person = person
    }
    func showGreeting() {
        let greeting = "Hello" + " " + self.person.firstName + " " + self.person.lastName
        self.view.setGreeting(greeting)
    }
}

class GreetingViewController : UIViewController, GreetingView {
    var presenter: GreetingViewPresenter!
    let showGreetingButton = UIButton()
    let greetingLabel = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        self.showGreetingButton.addTarget(self, action: "didTapButton:", forControlEvents: .TouchUpInside)
    }

    func didTapButton(button: UIButton) {
        self.presenter.showGreeting()
    }

    func setGreeting(greeting: String) {
        self.greetingLabel.text = greeting
    }

    // 佈局代碼
}
// 裝配 MVP
let model = Person(firstName: "David", lastName: "Blaine")
let view = GreetingViewController()
let presenter = GreetingPresenter(view: view, person: model)
view.presenter = presenter

裝配問題的重要說明

MVP是第一個揭示裝配問題的模式，因爲它有三個獨立的層。既然我們不希望View和Model耦合，那麼在顯示的View Controller（其實就是View）中處理這種協調的邏輯就是不正確的，因此我們需要在其他地方來做這些事情。例如，我們可以做基於整個App範圍內的路由服務，由它來負責執行協調任務，以及View到View的展示。這不僅僅是在MVP模式中必須處理的問題，同時也存在於以下集中方案中。

讓我們看看MVP的特點：

職責拆分 — 我們將最主要的任務劃分到Presenter和Model，而View的功能較少（雖然上述例子中Model的任務也並不多）。
可測性 — 非常好，基於一個功能簡單的View層，可以測試大多數業務邏輯
易用性 — 在我們上邊不切實際的簡單的例子中，代碼量是MVC模式的2倍，但同時MVP的概念卻非常清晰。

iOS 中的MVP意味着可測試性強、代碼量大。

MVP

關於Bindings和Hooters

還有一些其他形態的MVP —— Supervising Controller MVP（監聽Controller的MVP）。這個變體的變化包括View和Model之間的直接綁定，但是Presenter（Supervising Controller）仍然來管理來自View的動作事件，同時也能勝任對View的更新。

但是我們之前就瞭解到，模糊的職責劃分是非常糟糕的，更何況將View和Model緊密的聯繫起來。這和Cocoa的桌面開發的原理有些相似。

和傳統的MVC一樣，寫這樣的例子沒有什麼價值，故不再給出。

MVVM

綁定

我在MVP部分已經提到這點了，但是在這裏我們來繼續討論。
綁定是從OS X開發中衍生出來的，但是我們沒有在iOS開發中使用它們。當然我們有KVO通知，但它們沒有綁定方便。
如果我們自己不想自己實現，那麼我們有兩種選擇:

基於KVO進行綁定，如 RZDataBinding 和 SwiftBond
完全的函數響應式編程，例如ReactiveCocoa、RxSwift或者 PromiseKit

事實上，尤其是最近，你聽到MVVM就會想到ReactiveCoca，反之亦然。儘管通過簡單的綁定來使用MVVM是可實現的，但是ReactiveCocoa（或其變體）卻能更好的發揮MVVM的特點。

函數響應式框架有一個殘酷的事實：強大的能力來自於巨大的責任。當你開始使用Reactive的時候有很大的可能就會把事情搞砸。換句話來說就是，如果發現了一些錯誤，調試出這個bug可能會花費大量的時間，看下函數調用棧：

在我們簡單的例子中，FRF框架和KVO被禁用，取而代之地我們直接去調用showGreeting方法更新ViewModel，以及通過greetingDidChange 回調函數使用屬性。

import UIKit

struct Person { // Model
    let firstName: String
    let lastName: String
}

protocol GreetingViewModelProtocol: class {
    var greeting: String? { get }
    var greetingDidChange: ((GreetingViewModelProtocol) -> ())? { get set } // function to call when greeting did change
    init(person: Person)
    func showGreeting()
}

class GreetingViewModel : GreetingViewModelProtocol {
    let person: Person
    var greeting: String? {
        didSet {
            self.greetingDidChange?(self)
        }
    }
    var greetingDidChange: ((GreetingViewModelProtocol) -> ())?
    required init(person: Person) {
        self.person = person
    }
    func showGreeting() {
        self.greeting = "Hello" + " " + self.person.firstName + " " + self.person.lastName
    }
}

class GreetingViewController : UIViewController {
    var viewModel: GreetingViewModelProtocol! {
        didSet {
            self.viewModel.greetingDidChange = { [unowned self] viewModel in
                self.greetingLabel.text = viewModel.greeting
            }
        }
    }
    let showGreetingButton = UIButton()
    let greetingLabel = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        self.showGreetingButton.addTarget(self.viewModel, action: "showGreeting", forControlEvents: .TouchUpInside)
    }
    // layout code goes here
}
// 裝配 MVVM
let model = Person(firstName: "David", lastName: "Blaine")
let viewModel = GreetingViewModel(person: model)
let view = GreetingViewController()
view.viewModel = viewModel

讓我們再來看看關於三個特性的評估：

職責拆分 — 在例子中並不是很清晰，但是事實上，MVVM的View要比MVP中的View承擔的責任多。因爲前者通過ViewModel的設置綁定來更新狀態，而後者只監聽Presenter的事件但並不會對自己有什麼更新。
可測性 — ViewModel不知道關於View的任何事情，這允許我們可以輕易的測試ViewModel。同時View也可以被測試，但是由於屬於UIKit的範疇，對他們的測試通常會被忽略。
易用性 — 在我們例子中的代碼量和MVP的差不多，但是在實際開發中，我們必須把View中的事件指向Presenter並且手動的來更新View，如果使用綁定的話，MVVM代碼量將會小的多。

MVVM是非常有吸引力的，因爲它集合了上述方法的優點，並且由於在View層的綁定，它並不需要其他附加的代碼來更新View，儘管這樣，可測試性依然很強。

VIPER

把LEGO架構經驗遷移到iOS app的設計

VIPER是我們最後要介紹的，由於不是來自於MV(X)系列，它具備一定的趣味性。

到目前爲止，你必須同意劃分責任的粒度是很好的選擇。VIPER在責任劃分層面進行了迭代，VIPER分爲五個層次:

交互器（Interactor） — 包括關於數據和網絡請求的業務邏輯，例如創建一個實體（Entities），或者從服務器中獲取一些數據。爲了實現這些功能，需要使用服務、管理器，但是他們並不被認爲是VIPER架構內的模塊，而是外部依賴。
展示器（Presenter） — 包含UI層面（但UIKit獨立）的業務邏輯以及在交互器（Interactor）層面的方法調用。
實體（Entities） — 普通的數據對象，不屬於數據訪問層，因爲數據訪問屬於交互器（Interactor）的職責。
路由器（Router） — 用來連接VIPER的各個模塊。

基本上，VIPER的模塊可以是一個屏幕或者用戶使用應用的整個過程 —— 例如認證過程，可以由一屏完成或者需要幾步才能完成。你想讓模塊多大，這取決於你。

當我們把VIPER和MV(X)系列作比較時，我們會在職責劃分方面發現一些不同:

Model（數據交互）邏輯以實體（Entities）爲單位拆分到交互器（Interactor）中。
Controller/Presenter/ViewModel 的UI展示方面的職責移到了Presenter中，但是並沒有數據轉換相關的操作。
VIPER 是第一個通過路由器（Router）實現明確的地址導航的模式。

找到一個適合的方法來實現路由對於iOS應用是一個挑戰，MV(X)系列並未涉及這一問題。

例子中並不包含路由和模塊之間的交互，所以和MV(X)系列部分架構一樣不再給出例子。

import UIKit

struct Person { // Entity (usually more complex e.g. NSManagedObject)
    let firstName: String
    let lastName: String
}

struct GreetingData { // Transport data structure (not Entity)
    let greeting: String
    let subject: String
}

protocol GreetingProvider {
    func provideGreetingData()
}

protocol GreetingOutput: class {
    func receiveGreetingData(greetingData: GreetingData)
}

class GreetingInteractor : GreetingProvider {
    weak var output: GreetingOutput!

    func provideGreetingData() {
        let person = Person(firstName: "David", lastName: "Blaine") // usually comes from data access layer
        let subject = person.firstName + " " + person.lastName
        let greeting = GreetingData(greeting: "Hello", subject: subject)
        self.output.receiveGreetingData(greeting)
    }
}

protocol GreetingViewEventHandler {
    func didTapShowGreetingButton()
}

protocol GreetingView: class {
    func setGreeting(greeting: String)
}

class GreetingPresenter : GreetingOutput, GreetingViewEventHandler {
    weak var view: GreetingView!
    var greetingProvider: GreetingProvider!

    func didTapShowGreetingButton() {
        self.greetingProvider.provideGreetingData()
    }

    func receiveGreetingData(greetingData: GreetingData) {
        let greeting = greetingData.greeting + " " + greetingData.subject
        self.view.setGreeting(greeting)
    }
}

class GreetingViewController : UIViewController, GreetingView {
    var eventHandler: GreetingViewEventHandler!
    let showGreetingButton = UIButton()
    let greetingLabel = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        self.showGreetingButton.addTarget(self, action: "didTapButton:", forControlEvents: .TouchUpInside)
    }

    func didTapButton(button: UIButton) {
        self.eventHandler.didTapShowGreetingButton()
    }

    func setGreeting(greeting: String) {
        self.greetingLabel.text = greeting
    }

    // 佈局代碼
}
// 裝配 VIPER 模塊（不包含路由）
let view = GreetingViewController()
let presenter = GreetingPresenter()
let interactor = GreetingInteractor()
view.eventHandler = presenter
presenter.view = view
presenter.greetingProvider = interactor
interactor.output = presenter

讓我們再來評估一下特性:

職責拆分 — 毫無疑問，VIPER是任務劃分中的佼佼者。
可測性 — 不出意外地，更好的分佈性就有更好的可測試性。
易用性 — 最後你可能已經猜到了維護成本方面的問題。你必須爲很小功能的類寫出大量的接口。

什麼是LEGO

當使用VIPER時，你可能想像用樂高積木來搭建一個城堡，這個想法可能存在一些問題。也許，現在就應用VIPER架構還爲時過早，考慮一些更爲簡單的模式反而會更好。一些人會忽略這些問題，大材小用。假定他們篤信VIPER架構會在未來給他們的應用帶來一些好處，雖然現在維護起來確實是有些費勁。如果你也持這樣的觀點，我爲你推薦 Generamba 這個用來搭建VIPER架構的工具。雖然我個人感覺這是在用高射炮打蚊子。

總結

我們研究了幾種架構模式，希望你能找到一些困擾你的問題的答案。但毫無疑問通過閱讀這篇文章你應該已經認識到了沒有絕對的解決方案。所以架構模式的選擇需要根據實際情況進行利弊分析。
因此，在同一應用程序中混合架構是很自然的。例如：你開始的時候使用MVC，然後突然意識到一個頁面在MVC模式下的變得越來越難以維護，然後就切換到MVVM架構，但是僅僅針對這一個頁面。並沒有必要對哪些MVC模式下運轉良好的頁面進行重構，因爲二者是可以並存的。

讓一切儘可能簡單，但不是愚蠢。 —— 阿爾伯特·愛因斯坦

原文鏈接：https://www.jianshu.com/p/68aa6071c02e
關注微信公衆號：iOSSir，每日更新蘋果資訊、技術乾貨！

iOS架構設計：揭祕MVC, MVP, MVVM以及VIPER

爲什麼要糾結選擇什麼架構呢？

爲什麼要採用分佈式

爲什麼要可測試

爲什麼要易用性

MV(X) 簡介

MVC

曾經

蘋果的MVC

願景：

實際情況：

MVP

MVP 實現了Cocoa的MVC的願景

裝配問題的重要說明

MVP

關於Bindings和Hooters

MVVM

最新且是最偉大的MV(X)系列的一員

綁定

VIPER

把LEGO架構經驗遷移到iOS app的設計

什麼是LEGO

總結

碼農千千萬，你憑什麼說自己精通iOS！

程序員，你是選擇25k的996還是18k的八小時工作日？

iOS中常見的幾種加密方式總結！

程序員最討厭的9句話，你可有補充？

《都挺好》：蘇明哲的老婆吳非這句話戳中所有大齡程序員的痛點！

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結