惟一可行的 iOS 架構

原文連接

本文翻譯自 Amirzhan Idryshev 的 The only viable iOS architecture，請參考原文閱讀

讓我猜猜您看到這個標題時有何見解。

難道這是另外一篇煩人的博客文章，模仿了 MVC 並提供了一種替代的「super-duper pattern」，而實際上只留下了更多的問題？這就是我看到另外一篇有關 iOS 架構的文章時的想法。MVC，MVP，VIPER，RIBLET，Clean Swift等。這樣的文章有不少，它們的觀點和架構大相徑庭。

咱們的社區一直在爭論哪一種「模式」是最好的。可是問題是他們全都是狗屎。任何支持某種「模式」的論點都不使人信服。咱們嘗試使用一些「模式」，並陷入沒有「正常答案」的問題。最後，咱們獲得了一些尷尬的解決方案，而且有更多的誤解。全部這些看起來都很奇怪。咱們在這些爭飽食終日。老實說，我一開始並不想寫這篇文章，可是，最後仍是沒有控制住。

告訴我一個咱們應該使用的架構「模式」。甚至沒有。告訴我，至少一個，這並不奇怪。咱們擁有一百萬種架構，但沒有一種能真正幫助咱們，甚至沒有一種看上去是好的代碼組織方式。爲何？

爲了解決這個問題，咱們應該從新考慮一切，從頭開始。咱們將真正深刻在這些架構中，並會發現咱們犯的主要錯誤。

若是我告訴您，iOS 中只有一種可能的架構模式，甚至沒有任何模式？你會怎麼想呢？

繼續閱讀，您將瞭解 MVC 的每一個變體看起來如何奇怪，咱們在 iOS 社區中有多少誤解，以及咱們在設計應用程序體系結構時應該真正作些什麼。

初見

MVC

儘管開發人員爭論應該使用哪一種體系結構，但 Apple 已經向咱們提供了有關如何構建 iOS 應用程序的說明，即 MVC。

View 是用戶能夠在屏幕上看到的部分。Model 是「數據」。Controller 是它們之間的中介。它從 Model 獲取數據並在 View 上顯示給用戶，同時在 View 上處理用戶操做並將其傳輸到 Model。

看起來很好。若是遵循要 Apple 指南的話，爲何不使用 MVC 呢？由於乍一看，MVC 真的很糟糕。您可能知道，ViewController 的大小和維護難度。由於除了視圖和數據外，還有不少不一樣的邏輯，這顯然應該由 Controller 完成。

Controller 負責管理其擁有的視圖的視圖層次結構。他們響應視圖的加載，出現，消失等等操做。他們還傾向於處理咱們想脫離模型的模型邏輯以及咱們想脫離視圖的業務邏輯。這致使咱們遇到的第一個問題是 Massive View Controller。

MVVM

咱們並不喜歡這樣上面這種方式，所以開始尋找 MVC 替代方案。而且咱們找到了它們。

MVVM 添加了一個新層 ViewModel 來將代碼與 Controller 分開。 可是實際上，它並不能解決全部問題。ViewModel 應該真正包含什麼？當ViewModel 也變得像 Controller 同樣臃腫時，我該怎麼辦？社區也所以分裂爲喜歡 MVVM 的人和不喜歡 MVVM 的人。

MVP

解決此問題的另外一種嘗試是 MVP。它開始將 ViewController 視爲 View，全部邏輯都交給新類 Presenter。可是它並無流行起來，由於它看起來真的很奇怪。實際上，咱們只是將全部問題從 ViewController 轉移到 Presenter。

VIPER

而後，咱們認爲咱們須要進一步分解並建立了 VIPER。如今，全部代碼都進入視圖，演示者，路由器，交互器或實體之一。

在很短的時間內，VIPER 變得流行起來，可是後來咱們知道它有問題。這種體系結構須要大量協議，類以及層之間的數據傳遞。可是因爲某些緣由，全部這些額外的工做並不能使咱們的設計更好，更易讀。

其餘架構

最後，咱們無休止的去建立新架構。全部這些看起來都是個笑話。每一個新架構看起來都比之前的架構更奇怪。吉爾赫姆·蘭博（Guilherme Rambo）講過一個笑話，很好地描述了這種狀況的荒謬性。不管選擇哪一種架構，全部架構都是很差的。

可是正如我以前所說，這個問題有解決方案。我會告訴你咱們應該使用哪一種「模式」。您可能會感到驚訝，但實際上就是 MVC。我想要作的是從頭開始，從原始資料中閱讀 MVC，而後中止使用它。若是它還活着，也許還不算壞？

原始的 MVC

許多 iOS 開發人員抱怨 MVC。可是，若是我告訴您，我前面提到的全部 MVC 問題實際上都不存在的呢？諸如「Massive View Controller」，「模型就是數據」，「 ViewController作不少業務邏輯」等觀察都是虛構的。他們都是出於對真正的 MVC 的誤解而產生的。

人們對此有疑問的主要緣由是因爲 MVC 的過於簡化。說真的，當您聽到 MVC 時，您會怎麼想？ 「一共有 3 個類：Model 是數據，View 是視圖，Controller 在它們之間」。可是，MVC 並非那麼簡單。

MVC是一項很是艱鉅的工做的結果。它是由 Trygve Reenskaug 於 1979 年在施樂 PARC 的 Dynabook 項目上的提出的。Dynabook 是適用於全部年齡段兒童的我的計算機。這是一個真正的革命性項目。Dynabook 旨在使計算機易於使用，同時使用戶可以管理複雜的應用程序。那時，圖形界面的基礎和「用戶友好界面」的概念首先獲得了發展。

這個項目進行了大約十年。Reenskaug 總結了這十年在 MVC 中積累的 GUI 應用程序開發的主要思想和解決方案。

並無像「嘿，咱們在10年內建立了一種通用模式，您應該用它來解決任何問題」。這是咱們犯的根本錯誤。MVC 不是模式。這不是應用程序模塊分解的方案。沒有人能夠爲您提供具備必定數量的類的靈丹妙藥解決方案，由於沒人知道您的問題，應用程序的業務邏輯，域模型詳細信息和主要目標。您應該本身設計應用程序。如下是 Martin Fowler 描述 MVC 誤解的問題：

它一般被稱爲模式，可是我認爲將其視爲一種模式並非很是有用，由於它包含了許多不一樣的想法。在不一樣地方閱讀 MVC 的人不一樣，他們的想法也不一樣，並將其描述爲 「MVC」。若是這不會引發足夠的混亂，那麼您會獲得對 MVC 的誤解，這種誤解是經過層層傳遞而來的。

MVC 是一組架構思想和原則。MVC 是正式嘗試將具備圖形用戶界面的應用程序中的主要思想形式化的嘗試之一。這些想法仍然有意義，不只適用於 iOS 平臺。您能夠從 Trygve Reenskaug 的做品中瞭解有關 MVC 的信息。The original MVC reports¹ 與 The Model-View-Controller. It's Past and Present²。

MVC 的主要原則之一是將咱們全部的代碼劃分爲 Presentation 和 Domain Model。

Domain Model 是咱們應用程序的核心。這是它的主要部分。它由幾個業務對象組成，例如，諸如賬戶，產品，交易等實體。這些對象相關的邏輯稱爲業務邏輯。例如，「若是用戶賬戶上的錢不多，請給他折扣」。MVC 中的模型意味着整個 Domain Model，而不只僅是某個實體的一個啞模型（dumb model）。Domain Model 能夠包含一個對象，也能夠包含整個對象系統。這取決於業務邏輯的複雜程度。

Presentation 是用戶能夠看到並與之交互的內容。在 MVC 中，View 和 Controller 是 Presentation 的一部分。

馬丁·福勒（Martin Fowler）將此原則稱爲*「Separated Presentation」*³。

MVC 的核心，也是對後來的框架最有影響力的想法，就是我所說的「分離表示」。分離演示的背後思想是在建模咱們對現實世界的感知的領域對象和做爲屏幕上看到的 GUI 元素的演示對象之間進行清晰的劃分。領域對象應該徹底獨立而且能夠在不引用 presentation 的狀況下工做，它們還應該可以支持多個 presentation（可能同時支持）。這種方法也是 Unix 文化的重要組成部分，而且一直持續到今天，容許經過圖形界面和命令行界面來操縱許多應用程序。

所以，若是咱們的 Presentation 與 Domain Model 鬆散耦合的，而且無需任何 Domain Model 的詳細信息，同時 Domain Model 徹底獨立於Presentation，則咱們應用的設計將是清晰，可重用和可維護的。

該方案取自 Reenskaug 的報告。

其中的 Editor 是 Presentation 的最初表述。在此方案中，咱們能夠看到 MVC 不是 3 個部分。它更多地是關於按層而不是按類進行分解。重要的是，Presentation 應與 Domain Model 很是鬆散地耦合。理想狀況下，它應該僅取決於所需的接口，以便任何 Domain Model 均可以實現此接口。該方案的 Facade 模式代表，Domain Model 中有一個類能夠經過調用所需對象來實現此接口，所以 Presentation 不須要了解有關域模型中具體對象的任何知識。接口和外觀幫助咱們使 Presentation 和 Domain Model 之間的鏈接鬆散耦合。

可是 Domain Model 應該如何與 Presentation 通訊？例如，若是某些數據在「Domain Model」中發生了更改，則應如何通知 Presentation？這是 MVC 的另外一個原理。Domain Model 永遠不該該依賴於Presentation，即便是經過接口也是如此。Domain Model 所能作的就是發送有關某個事件的通知，而不知道誰將處理此事件。能夠經過觀察者模式來完成。這將使咱們徹底獨立於域模型。

Reenskaug 報告的另外一種方案描述了 MVC 的第三項原則。

這是關於 Input 和 Output 的分離表示。最初，將 Presentation 分爲負責向用戶顯示信息的層和負責從用戶獲取信息的層是一個很好的主意。 稍後您將看到，該原理不適用於 iOS。可是您應該知道，在原始 MVC 中， Controller 和 View 都具備圖形表示。

總而言之，原始 MVC 應該看起來像這樣：

這適用於iOS嗎？

固然能夠！若是咱們將 MVC 視爲一組原則，而不只僅是一個「具備 3 種類的模式」，咱們將永遠不會知道 「Massive View Controller」 問題。讓咱們看看這些原理如何適用於iOS。

如前所述，MVC 的核心是 Presentation 和 Domain Model 之間的強分離。實際上，該原理已成爲 GUI 應用程序設計中的主要原理之一。諸如 MVVM 或 MVP 之類的其餘體系結構也基於這種分離。不管您針對哪一個平臺編寫代碼，使用哪一種體系結構，都應始終進行這種分離。所以，這意味着該原則對 iOS 也很重要。

如何將視圖劃分爲 View 和 Controller？一般，它也適用於 iOS，甚至包含 UIView 和 UIViewController 的 iOS SDK。可是咱們應該知道，這種分離與原始 MVC 有一些區別。這並不奇怪，由於通過這麼長的時間，用戶界面也發生了變化。如今，咱們不須要在輸入和輸出上劃分圖形元素。特別是在 iOS 上，每一個 UIView 元素都可以顯示信息並接收用戶操做。所以，UIView 是一個類，具備圖形表示形式，並負責與用戶雙向交流。 UIViewController 是 UIView 的全部者。它「控制」 View 及其生命週期，在 View 上處理用戶操做，並在 View 上顯示 Model 中的信息。

原始 MVC 的這種變體具備不一樣的名稱，稍後咱們將看到它，可是不管如何，咱們將其稱爲 MVC，由於保留了主要原理，而且僅僅是 MVC 的變體。此外，蘋果公司自己稱之爲 MVC。

實際上，咱們如何稱呼它並不重要。重要的是要了解它是如何實現的。更確切地說，要意識到已經實現了 MVC。UIView 和 UIViewController 是已經在 iOS SDK 中實現的類。個人意思是，有些人拒絕 MVC，但仍使用 UIView 和 UIViewController。儘管這是主要問題，但它使 Apple MVC 與其餘體系結構有所不一樣。這是咱們如何處理用戶交互的一種方式，而諸如 Interactor 或 Presenter 之類的其餘類則不會更改這種方式。相反，MVC 在必要時根據問題涉及其餘實體。儘管 Interactor 和 Presenter 都是很差的類的示例，但咱們應該記住 MVC 並非一種模式，能夠根據須要提供許多類來解決問題。所以，若是您在用戶面前使用 UIView 和 UIViewController，則沒必要介意建立其餘哪些類，您可使用 Apple MVC。

咱們能不使用 UIView 和 UIViewController 嗎？能夠！許多工做在後臺進行，所以咱們能夠輕鬆地經過咱們的應用程序處理用戶的全部通訊。除了這兩個類以外，還有不少其餘東西：響應者鏈，UIEvent，UIView 層次結構，UIView 生命週期，Hit Testing，UIControls，UIGestureRecognizers 等。全部這些都是 Apple MVC。這意味着 MVC 不是咱們的選擇。若是您說本身不使用 MVC，然而事實並不是如此！咱們使用了 MVC，而且在 iOS 中不能使用任何替代方法。

使用 iOS SDK 進行戰鬥是不可能的，任未嘗試都會使系統複雜化。可是，若是咱們瞭解這一點，就還不錯。一旦咱們中止與 iOS SDK 的對抗，全部這些東西就會變得有用。SDK 開始幫助咱們並從中受益。每一個 UIViewController 都擁有一個根 UIView。咱們能夠在 interface builder 中繪製視圖而無需任何代碼，並將全部用戶操做連接到UIViewController。 UIViewController 還經過諸如viewDidLoad()，viewWillAppear() 等方法處理 View 的狀態。咱們應該使用全部這些功能。

iOS SDK 爲咱們提供了許多功能。許多開發人員抱怨 UIViewControllers 變胖了，但其中只有一小部分提到了 UIViewControllers 分解功能。所以，對於許多開發人員而言，它可能會讓人感到驚訝。可是咱們能夠爲 1 個頁面建立多個 UIViewControllers。是的，若是一個屏幕上有多個邏輯上獨立的組件，咱們能夠將其分爲多個小 UIViewControllers。

• UIViewController 是表示層的一部分。若是您在此處編寫業務邏輯，網絡請求或其餘與用戶界面無關的內容，則不是 MVC。

• 若是須要，在表示層中建立其餘類。 IViewController 的存在並不會迫使您在此處編寫全部代碼。若是您有不少表示邏輯，請從 ViewController 中刪除它。可是請確保確實須要新實體。

• 不要與 iOS SDK 抗爭。它爲咱們提供了許多功能，若是咱們開始使用它們，這些功能將帶來巨大的好處。

咱們須要MVC替代品嗎？

好吧，答案很明顯：咱們不須要。您已經瞭解了什麼是真正的 MVC，以及如何在 iOS 中使用它。此外，使用本身的體系結構與 iOS 平臺抗衡幾乎是不可能的。可是，讓咱們再次考慮一下咱們在開始時描述的每種架構，您會發現它們在 iOS 環境中是多麼的奇怪甚至荒謬。

MVP

MVP 是其中最奇怪的一個。MVP 由 Mike Potel 於 1996 年推出，是對 MVC 的修改。在有關 MVP 的工做中，Potel 建議無需將小部件劃分爲「視圖」和「控制器」。現代操做系統的用戶界面已經在 View 類中提供了大多數 Controller 功能，所以 Controller 彷佛有點多餘。所以，刪除了 Controller 並建立了一個新類 Presenter 做爲 View 和 Model 之間的粘合劑。

等等，看起來像 Apple MVC 嗎？也許它就是 Apple MVC？蘋果本來想說是 MVP，卻說成了 MVC？我不知道，由於這些術語之間有太多混淆。讓咱們看看 Martin Fowler 在有關 GUI 體系結構的文章中如何區分 MVC 和 MVP。

MVP使用 Supervising Controller 來操縱模型。小部件將用戶手勢傳遞給 Supervising Controller。小部件未分爲視圖和控制器。您能夠將 presenters 看做是控制器，但無需最初處理用戶手勢。可是，還須要注意的是，presenters 一般是在表單級別，而不是在小部件級別 -– 這也許是更大的區別。

如今，看看 MVC 和 MVP 的這些方案。並將它們與咱們上面看到的 Apple MVC 方案進行比較。其中哪個與 Apple MVC 更類似？是的，Apple MVC 看起來更像是 MVP，而不是原始的 MVC。咱們如何稱呼它並不重要。Apple MVC 不管如何都與它們二者不一樣。

最重要的是要了解咱們已經擁有充當 UIView 持有者的 UIViewController。這意味着咱們不須要具備 Presenter 或 Controller 角色的其餘任何類。

所以，嘗試建立一個新的 Presenter 類並將 UIViewController 視爲一個視圖是沒有意義的。儘管我說過，除了 UIView 和 UIViewController 以外，Presentation 層中可能還有其餘類，可是 Presenter 是這樣作的一個很差的例子。這是與 iOS SDK 對抗的一個示例。不管咱們是否但願將 UIViewController 視爲 View 多少，它仍然是Controller（或者您能夠將其稱爲 Presenter）。在 iOS 中，MVP 方案實際上以下所示：

咱們真的須要這個新類嗎？這看起來很奇怪，由於咱們只是建立了具備徹底相同角色的 UIViewController 的副本。若是沒有給咱們帶來任何收益，咱們爲何應該轉移全部用戶操做，將全部視圖狀態從 Controller 更改成 Presenter？它只會給咱們帶來額外的代碼和複雜性。確實很難將每一個動做委派給 Presenter。一樣，不要與 iOS SDK 對抗，咱們沒法將 UIViewController 轉換爲 View。即便能夠，也沒有必要。

VIPER

還記得我說過 MVP 是最奇怪的嗎？不，VIPER 纔是。由於，除了 MVP 的全部問題（它還會重複 Presentation 層中 MVP 的全部錯誤，包括複製 Presenter 以及將 UIViewController 轉換爲 View 的嘗試失敗），VIPER 還試圖將咱們的 Domain Model 劃分爲 Interactor，Service 和 Entity 類。

VIPER 是如何被建立的？是否有本身的歷史記錄，例如 MVC 或 MVP？是的，的確如此，可是歷史並不那麼光鮮。 VIPER 於 2013 年建立，旨在解決 Apple MVC 問題。

因爲許多應用程序邏輯不屬於模型或視圖，所以一般會在控制器中處理。這致使了一個稱爲 Massive View Controller 的問題，在該問題中，視圖控制器最終會作太多事情。

以上引用來自有關 VIPER 的原始帖子。這意味着 VIPER 的建立是爲了解決不存在的 「Massive View Controller」 問題。它是基於 「MVC是具備3種類和巨大的UIViewController的模式」的錯誤思想而建立的。爲了解決這個「問題」，VIPER 按 5 類進行了更多分解。可是實際上，您的「架構」有多少個字母並不重要。若是您僅將應用程序體系結構視爲具備確切類的「模式」，則不管如何都會失敗。類的數量是有限的，可是每次的邏輯可能會更寬，而且有朝一日咱們的 Interactor 或另外一個類將與 Massive View Controller 同樣大。

並且，邏輯可能真的不一樣。可是在 VIPER 中，即便邏輯很小或很是具體，咱們也老是建立 5 個類。問題確實有所不一樣，而且沒有適合全部問題的方案。咱們應該根據此特定邏輯單獨進行分解。在 OOP 中，常見的任務是瞭解咱們應該建立哪些實體，如何將它們彼此關聯以及如何命名它們，從而以最清楚地描述代碼。

克里斯·艾德霍夫（Chris Eidhof）在《App Architecture》一書中對 VIPER 問題和分解有不少想法。

雖然接口分解是一種管理代碼大小的有效方法，但咱們認爲應該按需執行，而不是有條不紊地針對每一個視圖控制器執行。分解應該與所涉及的數據和任務的知識一塊兒執行，以即可以實現最佳的抽象，從而能夠最大程度地下降複雜性。

Interactor 是否有這麼好的抽象性？答案是否認的。「Interactor 是包含業務邏輯的類」。這有助於咱們理解代碼嗎？它包含哪些業務邏輯？若是我有不少業務邏輯怎麼辦？咱們應該建立並命名咱們的實體，使其清晰明確，而不只僅是通用的「Interactor」。

爲全部問題建立相同的類，而且每次僅將代碼添加到這些類中並非一個好的設計。它甚至都不是 OOP，我認爲這是具備 5 個文件的過程編程。

我認爲，VIPER 是一個很大的錯誤。VIPER 證實咱們還不瞭解 MVC。個人建議是忘記 VIPER，不要討論它。

MVVM

若是咱們不使用 UIViewController 編寫業務邏輯並使用分解將一個屏幕劃分爲多個 UIViewControllers，那麼咱們的 UIViewControllers 永遠不會變得很大嗎？ 好吧，這取決於它具備多少表示邏輯。

咱們來看一個例子。

// Domain Model Object
struct Person {
    let name: String
    let gender: Gender
}
class ViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        // presentation logic 
        if person.gender == .male {
            nameLabel.text = "Mr." + person.name
        } else {
            nameLabel.text = "Mrs. " + person.name
        }
    }
}
複製代碼

在上面的示例中，咱們有一個表示邏輯，能夠根據人的性別來格式化其姓名標題。這個邏輯應該在 UIViewController 中嗎？若是存在不少複雜的表示邏輯怎麼辦？除了複雜性以外，還存在測試問題。測試 UIViewController 類並不容易。這也是開發人員建立本身的 Presenter 並將全部邏輯移至這個 NSObject 子類的另外一個緣由。可是咱們已經看到了這種方法的問題。

咱們能夠在 Person 類中編寫此邏輯嗎？好了，在這種狀況下，咱們將根據 MVC 原理將表示和業務邏輯混合在一個很差的類中。很難理解爲何有此代碼。咱們看不到該代碼是針對哪一個具體視圖編寫的。最後，很難在不一樣的屏幕上重用此模型。若是在其餘頁面上以不一樣方式顯示此信息（例如表情符號）怎麼辦？

如今，該再次重申 MVC 不是模式。是的，咱們在 Presentation 層中有一些邏輯，MVC 不會強迫您在現有的類中編寫此邏輯。咱們能夠建立一個新類並在那裏封裝具體邏輯。馬丁·福勒（Martin Fowler）寫了這個問題。他說，若是與 Domain Model 對象不一樣，咱們能夠在 Presentation 層中建立其餘模型。他稱其爲「對象表示模型(Presentation Model)」。

struct PersonPresentation {
    let name: String
    init(person: Person) {
        if person.gender == .male {
            name = 「Mr.」 + person.name
        } else {
            name = 「Mrs. 「 + person.name
        }
    }
}
複製代碼

如今，在 UIViewController 中，咱們僅將名稱映射到標籤。 您可能會說它是 MVVM。但事實並不是如此。儘管咱們將其稱爲 MVVM，但事實並不是如此。由於實際上，MVVM 於 2005 年建立，是對 MVC 和 MVP 的修改。添加了 ViewModel 而不是 Controller 和 Presenter，它能夠處理 View 操做。可是在 iOS 中，咱們仍然沒有擺脫 Controller。UIViewController 處理咱們與用戶交互的方式。咱們要作的就是在 Presentation 層中建立一個額外的模型，這在 MVC 中是隱含的。咱們只是使用了一個 Presentation Model。

可是一樣，命名並非一個大問題。固然，咱們不會將全部 ViewModels 重命名爲 PresentationModels。可是，咱們應該瞭解 ViewModel 的真正含義（爲避免混淆，如今將其稱爲 PresentationModel）。

PresentationModel 不是包含全部業務邏輯的類，不少開發人員都這麼說。 PresentationModel 不是將網絡請求，數據庫請求，緩存等組合在一塊兒的外觀。它只是 Presentation 層中的模型。使用 PresentationModel 並不意味着咱們使用另外一種架構。咱們仍然使用 MVC，由於咱們不會更改與用戶交互的方式。

一般，PresentationModel 只是一種模式。是的，與 MVC 或原始 MVVM 不一樣，Presentation Model 是一種在確實須要時使用的模式。無需進行標準化，也無需無端在每一個模塊上建立 PresentationModel。

結論

MVC 不像具備 3 種類的方案那麼簡單。MVC 不是模式，而是一組架構思想和原則。

這些原則的核心是 Presentation 和 Domain Model 之間的強分離。MVC 中的模型表示整個域模型。UIViewController 是 Presentation 的一部分。這意味着 MVC 不容許咱們建立一個啞實體並將全部業務邏輯移至 UIViewController。

這種分離已成爲 GUI 應用程序設計中的主要分離之一，它們對 iOS 也頗有用。可是表示層分離一般是特定於平臺的。iOS SDK 已經完成了大量工做，所以咱們能夠輕鬆地經過咱們的應用程序處理用戶的全部交流。所以，MVC 不是咱們的選擇，咱們沒法更改與用戶交互的工做方式。咱們不該該與平臺對抗，由於咱們的設計會很複雜。可是，一旦咱們中止與 iOS SDK 對抗，全部這些人員就會變得有用。

除了根據業務邏輯設計域模型外，咱們還能夠根據表示邏輯設計表示。 MVC 不會強迫咱們在 UIViewController 中編寫全部代碼。若是須要，咱們能夠在 Presentation 層中建立其餘類。可是，若是您添加 ViewModel 或 Coordinator 或其餘名稱，則不要將其稱爲新架構。

最後，請勿嘗試將架構標準化爲模式。根據特定的邏輯分別進行分解，以試圖清楚地描述代碼。

不要責怪 MVC。

參考

[1]http://folk.uio.no/trygver/2007/MVC_Originals.pdf [2]http://heim.ifi.uio.no/~trygver/2003/javazone-jaoo/MVC_pattern.pdf [3]https://martinfowler.com/eaaDev/SeparatedPresentation.html