MVP vs MVC vs MVVM vs VIPER。 什麼更適合 iOS 開發？

就像每個房子都有一個堅實的地下室，每個軟件項目都有一個構建它的軟件架構，每個項目都有自己的應用程序結構。 架構模式的類型可能會有所不同，但最常用的有 4 種——整個 IT 界不斷批評但同時繼續使用的模式： MVC、MVP、MVVM 和 Viper （最後一種作為 iOS 架構模式居多） . 本文將進一步介紹這些模式的比較以及為每個 Swift 編寫的項目案例選擇更合適的模式。

按照時間順序，一旦第一個軟件設計模式出現，那些 ios 開發架構模式的常見問題很快就出現了。

例如，服務器-客戶端通信的問題——一個人如何與另一個人交互？ 或者不同的 - 將應用程序的業務邏輯與應用程序內的邏輯分離的問題； 這個在應用程序架構方面應該如何執行？ 由於它們，不同架構層的各種設計模式已經見識過世界； 其中最著名的是：

- 單例設計模式。

這種模式允許一個類只應用於一個對象，當系統批准有限數量的實例（或僅一個實例）時，此選項有用。

- 裝飾器設計模式。

與單例相反，這種模式（也稱為 Wrapper 和 Adapter 模式）允許將特定行為添加到單個對象（靜態或動態），並且所有這些都不會影響其他對象的行為一個共享一個類。

- 橋樑設計模式。

由臭名昭著的四人幫的作者《設計模式》首先介紹，這種架構模式“使用封裝、聚合，並且可以使用繼承將職責分離到不同的類中。當一個類經常出現時，面向對象的特性編程變得非常有用，因為只需對程序的先驗知識最少，就可以輕鬆更改程序代碼。 [來源：維基]

儘管這些模式大不相同，但代碼編寫者的共同問題在每個人身上都發生了。 例如，Singleton 的“質量”。 Singleton 過於全局化，因為您的代碼的依賴關係深深地隱藏在您的應用程序中，而不是在接口中公開。 這就是為什麼在軟件開發過程中不斷出現新模式的原因。

4 種最常用的模式是MVC、MVP、MVVM 和 VIPER （主要用於 iOS）。

按照列出的順序開發，它們都有自己的優點和缺陷，引起了許多關於每個應用程序的爭議。 多關注他們實施的最佳實踐可能會使事情變得更清楚。

MVC模式

所有軟件模式的祖父，於 1970 年代初由挪威計算機科學家 Trygve Reenskaug 首次引入，模塊 - 視圖 - 控制器，廣為人知的 MVC，是面向對象編程的首批模式方法之一。

View 部分負責為系統用戶顯示所有內容（移動或 Web 應用程序的界面等）。 模型一般負責數據庫、業務實體和其餘數據。 反過來，控制器調節模型的工作，提供給數據庫的數據，從提到的數據庫顯示到視圖部分，反之亦然。

無論 MVC 模型多麼通用，兩個最大的競爭對手——蘋果和谷歌都有自己的模式來表示模型 - 視圖 - 控制器系統。 Apple 系統的問題在於 View 和 Controller 部分之間的緊密連接，緊密到幾乎將 View 和 Controller 結合在一起，而將 Model 部分分開。

因此，這會導致測試過程不佳 - 只能檢查模型，根本無法測試 V&C（由於它們之間的緊密連接）。

當涉及到軟件時，控制器和視圖段之間的強大連接被證明是真正“不健康”的，因此一種新模式很快就出現了。

MVP 模式。

我們中的許多人都在最小可行產品的上下文中聽說過這個捷徑，但就軟件工程而言，它意味著不同的東西。 Model View Presenter 模式的關鍵點很少，在它和 MVC 之間形成了巨大的鴻溝：

MVP模型

• 視圖與模型的耦合更鬆散。 Presenter 負責將模型綁定到視圖。

• 更容易進行單元測試，因為與視圖的交互是通過接口進行的。

• 通常查看到演示者 = 一對一映射。 複雜的視圖可能有多個演示者。

MVC模式

• 控制器基於行為，可以跨視圖共享

• 可以負責決定顯示哪個視圖
  [來源：基礎設施]

在這種安排中，Model 的功能保持不變； Presenter分別負責業務邏輯。 V 部分是特別有趣的部分 - 因為它分為兩部分 View 和 View Controller，它們是交互的權威。 當出現 MVVM vs MVC 問題時，這種類型的系統解決了 MVC 模式中曾經存在的“重度依賴”視圖和控制器模式的問題。

在這種情況下，測試障礙也得到了解決，因為模型、具有用戶交互的視圖和演示器部件 - 所有這些都可以進行測試。
尚存在的不便在於 Presenter 的部分——但過於龐大，但考慮到了所有現有的業務邏輯。 這就是為什麼下一幕開始發揮作用的原因，名為……

MVVM 模式

2005 年，Microsoft 的架構師之一 John Gossman 創建了Model-View-ViewModel軟件架構模式。 MVVM模型的三個核心組件分別是：
模型是“應用程序域模型的實現，包括數據模型以及業務和驗證邏輯。 模型對象的示例包括存儲庫、業務對象、數據傳輸對象 (DTO)、普通舊 CLR 對象 (POCO) 以及生成的實體和代理對象。” [來源：微軟]

視圖再次是用戶能夠看到的一切 - 屏幕上所有內容的佈局、結構和外觀。 基本上，在應用程序中，它將是應用程序的頁面。 View 只對 ViewModel 獲取和發送更新，不包括這部分和 Model 本身之間的所有通信。

ViewModel 應該是 View 和 Model 系統組件之間的“互連鏈”，它的主要功能是處理 View 的邏輯。 通常，視圖模型通過調用模型類中的方法與模型交互。 正如微軟所說，視圖模型然後以視圖可以輕鬆使用的形式提供來自模型的數據。

MVC 和 iOS MVVM 的主要區別在於MVVM 的分佈模式比之前列出的 MVC 更好，但與 MVP 相比，它也大量過載。 在這裡測試是一個特別重要的問題，因為雖然簡單地編寫代碼，但您不能保證整個項目會正常運行——從光明的角度來看，測試有助於確保它會正常運行。

下一個架構模式的演變最近已經發布，現在是最新鮮的軟件架構方法。

iOS VIPER 架構

為了尋找最佳的架構解決方案，世界各地的 iOS 開發人員遇到了所謂的“清潔架構”方法，這種方法由鮑勃叔叔在 Clean Coders 上引入 - 一個為全球軟件專業人士提供培訓課程的知名平台。

Clean Architecture 將應用程序的邏輯結構拆分為多個職責級別。 反過來，這種“分離”解決了緊密的依賴問題並提高了所有級別的測試可用性。

ios開發的VIPER

VIPER 是針對 iOS 構建的應用程序的 Clean Architecture 的實現。 作為所有模式名稱的通用規則，它也是 View、Interactor、Presenter、Entity 和 Routing 的反義詞。 VIPER 的每個部分都負責特定的元素，特別是：

1. 視圖負責反映用戶對界面所做的操作

2. 在 VIPER 模式中，Presenter 的職責非常有限——它接收來自 Entity 的更新，但不向它發送任何數據；

3. 交互器是系統中實際與實體對應的部分。 該方案按以下方向工作：Presenter 將 View 模型中的更改通知給 Interactor，然後 Interactor 聯繫 Entity 部分，並將從 Entity Interactor 接收到的數據返回給 Presenter，Presenter 命令 View 為用戶鏡像。 所有數據模型、所有實體和所有網站都連接到交互器部分。

4. 實體由由交互器控制的對象（標題、內容等）組成。它從不直接與演示器交互，僅通過 I 部分。

5. 路由（或有時稱為線框）負責所有屏幕之間的導航，並且本質上是路由。 Wireframe 控制 UIWindow、UINavigationController 等對象。

尤其是在 iOS 架構系統中，它都是建立在一個叫做 UIkit 的框架之上的，它包含了 Apple MVC 的所有組件，但沒有一個緊密的聯繫，這種聯繫曾經讓程序員發瘋。

一旦涉及到單元測試，VIPER 模塊也很有用，因為偉大的模式的分佈讓您可以測試所有可用的功能。 在許多方面，這是開發人員在使用以前的 MVC、MVP 和 MVVM 軟件模式時面臨的主要困難。

為這一切加冕。

所有這 4 種軟件設計模式通常都被稱為 iOS 開發的最佳架構模式之一，儘管它們都不太理想，而且絕對不能普遍用於您要開發的每個項目。 令人沮喪的是，以下是每個模式存在的問題的簡短列表：

• MVC、MVP、MVVM——它們都有這個“緊密連接”的問題，這使得在開發中引入更新並在之後測試它們是一項非常艱鉅的任務。

• VIPER vs MVVM, MVC or MVP ，被認為是一個勝利的案例； 儘管儘管它具有高度的靈活性和出色的可測試性，但也有許多難以產生的細微差別。

有100%固溶體嗎？ 並非如此，但對於您的每個項目，這 4 種 iOS 應用程序模式之一可能正是您所需要的。 如果不是，那麼兩者的混合將是。 或者甚至可能是三個。 據說財富偏愛大膽的人，那麼您為什麼不大膽地玩弄軟件設計模式呢？

由 Max Mashkov 和 Elina Bessarabova 撰寫。