【Android】 MVC, MVP, MVVM 到底是什麼 - Android開發為例 ?

從開始寫程式以來，雖然會自己把 Activity, Database 之類的用不同的資料夾來區分，也沒在管什麼MVC, MVP更不用講今天要提到的MVVM。但隨著Android Jetpack的推出，提供一些好用的方法來實現MVVM架構，這邊就來釐清一下到底什麼是MVC, MVP, MVVM。

設計架構

MVC (Model / View / Controller)

MVC架構中，把程式分成了三個層級：

• M：Model － 負責處理與資料相關的事情，包括取得資料、儲存資料等等。
• V：View － 如字面上所示，就是與介面相關的東西。
• C：Controller － 介於View及Model之間的橋樑，接收來自View的事件，去操控Model的資料。

Android 中的 MVC

在Android的世界中可以將Layout的XML視為View，data class視為Model，而Activity或Fragment則是Controller。
這樣的架構看似很完美，但其實執行起來有他的困難點，首先View上元件的操控通常會寫在Activity或Fragment當中，導致Activity或Fragment需同時負責View及Controller的事情，當介面越複雜、要處理的邏輯越多時，Activity或Fragment的程式碼就會變得又臭又長。

MVP (Model / View / Presenter)

MVP架構中所提及的M及V就如同MVC架構中的M及V一樣，而P：Presenter則是擔任View及Model之間的橋樑。

Android 中的 MVP

在MVP中與MVC較不同的是，這裡的View通常除了指Layout檔外，Activity及Fragment也被歸類於此，而Presenter則是負責邏輯處理的部分。這樣的好處是可以將分工分的更細，以利後續的維護或是重複利用性。而在MVP架構中會多一個Contract類別，主要是定義View及Presenter之間互動的Interface層。但也因如此，日後若需修改時，會需要連Interface一併修改，稍嫌麻煩。

MVVM (Model / View / ViewModel)

如同前面所提到的，自從Android Jetpack推出之後，MVVM的架構逐漸變成了主流。MVVM當中的ViewModel，主要是負責接收來自View的事件，去操控Model的資料，但這邊最主要的不同是，View的更新是由Model中的資料來驅動的，當資料有所更動的時候，UI會自動做相對應的呈現。

Android 中的 MVVM

在MVVM中最重要的特點就是資料變成很重要的一項因素，因為事件的觸發會變成是由資料的變動而觸發的。在MVC/MVP中，當資料發生變動時需要自己去控制元件的變化，也就是在Model當中必須要知道他的View是誰然後再去更新他，但在ViewModel中，則不需要知道View是誰，因為需要被更動的View會自己去監控資料是否變動了，這樣的好處就是ViewModel只需要好好的負責與Data相關的事情，在ViewModel中就不需要寫一堆控制View的程式碼，只需要專心管理流程，而Activity跟Fragment則專心操控介面及生命流程。

但MVVM這麼神奇到底是怎麼做到的，有賴Android所提供的下列元件：

• ViewModel
• LiveData
• Room
• DataBinding

這四項元件就之後再慢慢寫吧。