如果是一個人開發 App，不會有人管你怎麼寫、怎麼設計，反正自己開心就好。

但是如果是一群人同時在開發一個 App，這時候，層次分明、分工明確、模組化的設計架構就相當重要了，不但看起來賞心悅目，對於程式的維護性、修改性、擴充性、還有效能都能大幅提升，從好幾個人開發一個 App，變成一個團體為了一個共同的目標在合作。

MVC

說到設計架構，最一開始的就是 MVC，MVC 是 Model-View-Controller 的縮寫，
Model 處理數據，View 顯示畫面，Controller 則是兩者的一個橋樑。

View 與使用者直接互動，當 View 接收到使用者的回饋需要拿資料時(ex: 點擊下一頁的按鈕執行換頁)，呼叫 Controller，
請 Controller 操作 Model 拿取想要的資料，Model 拿到資料後直接把資料丟回給 View，把資料顯示給使用者

以上大致上是 MVC 的運作流程，而 Android Studio 把 view 放在 xml，操作 view 的程式碼放在 java class 的作法就能算是一種 MVC 模式。

優點

• 非常的直覺，好懂
• 使用 Controller 將 Model 和 View 分開來，具有一定程度的解耦合

缺點

• 三者相互依賴，一但更新了其中一者，另外兩者也必須跟著修改
• 隨著不斷的開發和添加功能，Controller 的代碼會越來越臃腫
• 難以進行單元測試

MVP

為了改善以上的缺點，MVP 將 Controller 換成了 Presenter

和 MVC 不同的是，Model 層拿到數據後，並不直接傳給 View 更新，而是交還給 Presenter，Presenter 再把數據交給 View，並更新畫面。

優點

• 從三者相互依賴變成都只依賴 Presenter (要改動的地方變少了)
• 責任分明，分工明確
  View 只負責收到使用者回饋後，呼叫 Presenter 拿取數據，並在接收到數據的時候，更新畫面。
  Model 被動的接收到 Presenter 命令，拿取資料，並回傳給 Presenter。
  Presenter 透過介面與 View 和 Model 溝通，是 View 和 Model 的唯一連結窗口。
• 方便進行單元測試　
  由於 Presenter 對 View 是透過介面進行操作，在對 Presenter 進行不依賴 UI 環境的單元測試的時候，可以 Mock 一個 View 對象，單元測試的時候就可以完整的測試 Presenter 業務邏輯的正確性。

缺點

• 隨著不斷的開發和添加功能，Presenter 的代碼會越來越臃腫

MVVM

不管是 MVC 還是 MVP，都無法避免 Presenter(Controller) 的代碼會越來越臃腫的問題，如果能達到一樣的效果(外部行為)，程式碼當然是越少越好囉(內部行為)，於是 MVVM 誕生了。

Model-View-ViewModel 透過觀察者模式將 View 和 Model 巧妙地連接在一起，
一旦 Model 的數據發生變化，觀察者 View 就能夠感應到這個更動，並把數據更新到 UI 畫面上，ViewModel 甚至不需要持有 View 的引用，更方便進行單元測試。

優點

• 很潮
• 大幅減少代碼量，省去了 MVP 中用來連接彼此的介面，Model 層數據更新後也不必透過介面 callback 給 view，因為 View 會透過 observe 感知數據的變動並更新 UI 元件。
• 可以搭配 DataBinding、LiveData 等框架使用，能更方便地處理 UI 的更新，生命週期的處理。
• ViewModel 能夠簡單地保存數據，且可以被多個 View 共享(MVC、MVP 也可以但較不適合)，View 與 View 之間傳遞數據也更方便(只有 MVVM 可以)。
• 撰寫測試時，MVP 需要 Mock 一個 View 對象才能進行測試，而 MVVM 由於 ViewModel 不需持有 View 的引用，更方便進行單元測試。
• 與其他框架的整合性強。由於 ViewModel 是 Google 開發的，在與其他也是 Google 開發的框架像是 Room、Paging 等搭配時就能使用他們整合出來的 api，相容性佳 。

缺點

• 入行門檻、學習成本高，且需要搭配 DataBinding、LiveData 等框架，才能發揮最大效益。

有任何問題或講得不清楚的地方歡迎留言和我討論。

更歡迎留言糾正我任何說錯的地方！

下一篇：ViewModel (一) 介紹與基本使用