如何在 Android 中實現 MVC

MVC、MVP 和 MVVM 是三種常見的架構設計模式，目前 MVP 和 MVVM 的使用比較廣泛，當然 MVC 並沒有過時。

MVC（Model-View-Controller），標準 MVC 如下所示：

簡友 說：

缺點：

MVP（Model-View-Presenter）是MVC的演進版本，主要部分如下：

簡要介紹：

解釋：

優點：

缺點：彎曲

MVVM 是 model-view-viewmodel 的簡寫。 與MVP模式相比，MVVM模式用viewmodel代替了presenter，其他層與MVP模式基本相同，viewmodel可以理解為檢視的資料模型和presenter的組合。 嵌入 MVVM 將檢視的狀態和行為抽象化為其中，從而允許我們將檢視 UI 與業務邏輯分開。

簡要介紹：

缺點：參考：

MVC（模型檢視控制器） MVC 應用程式始終由這三個部分組成。 事件導致控制器更改模型和/或檢視。

一旦控制器更改了模型的資料或屬性，所有依賴檢視都將自動更新。 同樣，只要 contro

第 1 階段。 使用傳統的MVC，檢視對應各種布局檔案，但這些布局檔案沒有Web端那麼強大，能做的非常有限; 控制器對應的是 Activity，而 Activity 具有操作 UI 的功能，我們在這個層的實際專案中也會有很多 UI 操作，在檢視中也會做很多應該做的事情，當然控制器也包含了控制器應該做的事情， 比如各種事件的分布，而在第一層，我們會呼叫模型層來根據事件來操作資料，因此在實際專案中，活動所在的控制器非常繁重，層與層之間的耦合也很嚴重，不方便單元測試。

第二階段。 使用MVC-MVP的演化版，在MVP中將布局布局和活動作為檢視層，並新增表示者層，表示者層與模型層進行業務互動，完成後再與檢視層（即活動）互動重新整理UI。 這樣，業務邏輯的所有工作都交給了呈現者，減少了檢視層和模型層之間的耦合，簡化了活動中的工作。 然而，在實際專案中，隨著邏輯複雜度的增加，活動膨脹的缺點仍然體現出來，因為活動中仍然充斥著大量與檢視層無關的東西，比如各種事件的處理和分發，就像在MVC中一樣，檢視層和控制器**耦合在一起，無法自拔。

第 3 階段。