MVC vs MVP vs MVVM：常見的Android架構模式解釋

作為一名開發人員，您一定聽說過架構模式。 在我們的 Android 世界中，最知名的是MVC 、 MVP和MVVM 。 您可能知道它們的特點，但您知道它們的區別以及何時使用它們嗎？

如果你問自己這些問題，這篇文章就是給你的。

MVC – 模型-視圖-控制器

模型-視圖-控制器 (MVC)是一種有助於組織應用程序結構的架構模式。 它將其職責分為三層：模型、視圖和控制器。

需要安卓專家？

跟我們工作！

• 模型——數據層，負責管理業務邏輯並支持網絡或數據庫 API。 該模型使用遠程和本地數據源來獲取和保存數據。 這是處理業務邏輯的地方。
• View – UI 層，負責從 Model 到用戶的數據可視化。 它管理數據的呈現方式，包括圖形界面。
• 控制器——集成視圖和模型層的邏輯層。 控制器的工作是接管用戶輸入並確定如何處理它。

您可以在下圖中快速查看各個組件的通信方式：

這個怎麼運作？

多年來出現了幾種 MVC 變體，但我將在這裡提到兩個最流行的變體：被動模型和主動模型。

被動模型

在這個版本的 MVC 中，Controller 是唯一操縱 Model 的類。 為了很好地說明這個過程，我將使用下圖：

1. 控制器響應用戶的操作並聯繫模型。
2. 當模型改變時，控制器告訴視圖更新它的數據。
3. 視圖從模型中獲取更新的數據並將其顯示給用戶。

活動模型

在這個版本的 MVC 中，除了 Controller 之外的其他類操作 Model。

在這種情況下，使用了觀察者模式，並將視圖註冊為模型觀察者。 多虧了這一點，當模型發生變化時，視圖將不斷更新。

優點

1. MVC 模式極大地支持了分離問題。 它增加了代碼的可測試性並促進了其擴展，從而可以輕鬆實現新功能。
2. Model 類沒有引用 Android 系統類，因此非常容易進行單元測試。
3. 控制器不擴展或實現任何 Android 類。 它使單元測試成為可能。

缺點

1. 視圖與控制器和模型相關。
   • View 對 Model 的依賴主要是在高級 View 中造成麻煩。 為什麼？ 如果模型的角色是提供原始數據，那麼視圖將接管用戶界面邏輯的處理。
     另一方面，如果 Model 將直接顯示準備顯示的數據，我們將獲得同時支持業務邏輯和 UI 邏輯的 Model。
   • 模型的主動實現以指數方式增加了類和方法的數量，因為每種數據類型都需要觀察者。
   • 當視圖同時依賴於控制器和模型時，對 UI 邏輯的更改可能需要對多個類進行更新/更改，從而降低了模式的靈活性。
2. UI 邏輯處理不限於一類。 對於一個新手程序員來說，這是一個相當大的問題，Model、View 和 Controller 之間的職責分工機率非常高。
3. 隨著時間的推移，尤其是在具有貧血模型的應用程序中，越來越多的代碼開始被發送到控制器，使它們變得臃腫而脆弱。

概括

View 對 Model 的依賴以及 View 中的邏輯會顯著降低我們應用程序中代碼的質量。 我們可以通過選擇其他模式來減少這種危險，尤其是那些建議用於移動應用程序的模式。 在下面閱讀它們。

MVP——模型-視圖-演示者

Model-View-Presenter (MVP) 是一種架構模式，我們可以使用它來處理 MVC 模式的弱點。 它提供了模塊化、可測試性和更清晰、更易於維護的代碼庫。

MVP 將應用程序結構分為View 、 Model和Presenter層：

• 模型——類似於 MVC 模式。
• View ——UI層，負責以Presenter指定的方式將數據呈現給用戶。 它可以通過活動、片段或任何通用視圖來實現。
• Presenter – 在 View 和 Model 層之間進行調解的邏輯層。 它同時聯繫 View 和 Model 層並對用戶執行的操作做出反應。

這個怎麼運作？

在MVP中，View 和 Presenter 是完全獨立的，通過抽象相互通信。 Contract 接口類定義了它們之間的關係。 多虧了他們，代碼更具可讀性，層之間的聯繫也很容易理解。 如果您對實現細節感興趣，請閱讀 Model-View-Presenter：Android 指南。

值得一提的是，Presenter 不能有任何對 Android 特定 API 的引用。

請參閱下圖，以全面了解各個組件之間的數據交換過程。 出於本文的目的，此示例已簡化：

1. 用戶執行操作。
2. Presenter 對用戶的操作做出反應並向模型發送適當的請求。
3. 模型被更新，新數據被發送到 Presenter。
4. Presenter 準備要顯示的數據並將其發送到 View。
5. 視圖向用戶顯示數據。

優點

1. 我們可以輕鬆地測試 Presenter 邏輯，因為它不依賴於任何 Android 特定的視圖和 API。
2. View 和 Presenter 是完全分開的，這使得模擬視圖變得容易，使得單元測試比 MVC 中的更膚淺
3. 我們只有一個類來處理與視圖呈現相關的所有事情——Presenter。

缺點

1. Presenter和 Controller 一樣，傾向於積累額外的業務邏輯。 為了解決這個問題，分解你的代碼並記住創建只有一個職責的類。
2. 雖然這對於 Android 應用程序來說是一個很好的模式，但在開發小型應用程序或原型時會讓人感到不知所措。

概括

與 MVC 相比，這種模式要好得多。 它解決了 MVC 模式的兩個關鍵問題：

1. View 不再同時引用 Controller 和 Model。
2. 它只有一個類來處理與視圖表示相關的所有事情：Presenter。

MVVM – 模型-視圖-視圖模型

Model-View-ViewModel (MVVM) 是一種基於事件的模式。 多虧了這一點，我們可以對設計變更做出快速反應。 這種架構模式允許我們將 UI 與業務和行為邏輯分離，甚至比 MVC 或 MVP 的情況還要好。

• ViewModel – 處理將數據從模型傳遞到視圖層並處理用戶操作。 值得一提的是，它為 View 提供了數據流。
• 視圖——UI 層負責在圖形界面中呈現數據、系統狀態和當前操作。 除此之外，它初始化 ViewModel 並將其與 View 元素綁定（通知 ViewModel 用戶操作）。
• 模型——與 MVC 相同——沒有變化。

這個怎麼運作？

MVVM模式的思想主要是基於View層（Observer 模式）觀察ViewModel層中數據的變化，並通過數據綁定機制來響應變化。

MVVM 模式的實現可以通過多種方式實現。 但是，值得在其中包含數據綁定機制。 得益於此，視圖層的邏輯被最小化，代碼變得更有條理，測試也更容易。

如果 MVP 模式意味著 Presenter 直接告訴 View 要顯示什麼，則MVVM ViewModel會公開 View 可以關聯到的事件流。 ViewModel 不再需要像對 Presenter 那樣存儲對 View 的引用。 這也意味著現在不需要 MVP 模式所需的所有接口。

視圖還會通知 ViewModel 各種操作，如上圖所示。 因此，MVVM 模式支持 View 和 ViewModel 之間的雙向數據綁定。 View 有對 ViewModel 的引用，但 ViewModel 沒有關於 View 的信息。

優點

1. 單元測試更直接，因為您不會沉迷於視圖。 當模型在測試時發生變化時，驗證可觀察變量是否正確定位就足夠了。
2. ViewModel 對單元測試更加友好，因為它們只是公開狀態，因此可以在不測試如何使用數據的情況下進行獨立測試。 簡而言之，不依賴於視圖。
3. 只有 View 包含對 ViewModel 的引用，而不是相反。 這解決了緊耦合問題。 一個 View 可以引用多個 ViewModel。
4. 即使對於復雜的 View，我們也可以在同一個層次結構中擁有不同的 ViewModel 。

缺點

1. 在復雜的 UI 中管理 ViewModel 及其狀態有時對初學者來說是一個挑戰。

概括

MVVM結合了 MVP 提供的優勢，同時利用了數據綁定和基於事件的通信的優勢。 結果是模型控制盡可能多的操作的模式，具有高度的代碼分離和可測試性。

MVC vs MVP vs MVVM：比較

MVC vs MVP vs MVVM：總結

MVP 模式和 MVVM 模式都明顯優於 MVC 模式。 您選擇哪種方式實際上取決於您的喜好。 但是，我希望本文向您展示了它們之間的主要區別，並使您更容易做出選擇。

尋找替代方案？

選擇跨平台！

參考書目：

1. Cervone, S. (2017) Model-View-Presenter：Android 指南。
2. Dang, AT (2020) MVC vs MVP vs MVVM。
3. Muntenescu, F. (2016) Android 架構模式第 1 部分：模型-視圖-控制器。
4. Muntenescu, F. (2016) Android 架構模式第 2 部分：模型-視圖-演示者。
5. Muntenescu, F. (2016) Android 架構模式第 3 部分：模型-視圖-視圖模型。