MVC / MVP / MVVM 架構(gòu)模式

Android架構(gòu)，即為開發(fā)Android時使用的架構(gòu)。Android的開發(fā)一般分為三部分：UI邏輯，業(yè)務(wù)邏輯和數(shù)據(jù)操作邏輯。

Android架構(gòu)，就是為了更好地協(xié)調(diào)這三者的關(guān)系。達(dá)到：

• 各模塊高內(nèi)聚低耦合的狀態(tài)，方便進(jìn)行團(tuán)隊(duì)分工合作開發(fā)。

• 代碼思路清晰，提高代碼的可維護(hù)性與可測試性。

• 減少樣板代碼，提高開發(fā)效率，減少開發(fā)錯誤。

MVC

Android上的MVC架構(gòu)我認(rèn)為是來源于web開發(fā)的SpringMVC，MVC全名為Model-View-Controller，圖解如下：

0

View：負(fù)責(zé)與用戶交匯，顯示界面。

Controller：負(fù)責(zé)接收來自view的請求，處理業(yè)務(wù)邏輯。

Model：負(fù)責(zé)數(shù)據(jù)邏輯，網(wǎng)絡(luò)請求數(shù)據(jù)以及本地數(shù)據(jù)庫操作數(shù)據(jù)等。

在MVC架構(gòu)中，Controller是業(yè)務(wù)的主要承載者，幾乎所有的業(yè)務(wù)邏輯都在Controller中進(jìn)行編寫。而View主要負(fù)責(zé)UI邏輯，而Model是數(shù)據(jù)邏輯，彼此分工。

MVC的本質(zhì)就是按照UI邏輯、業(yè)務(wù)邏輯、數(shù)據(jù)操作邏輯不同的職責(zé)分三大模塊，彼此分工。

在Android中，View一般使用xml進(jìn)行編寫，但xml的能力不全面，需要Activity進(jìn)行一些UI邏輯的編寫，因而MVC中的V即為xml+Activity。Model數(shù)據(jù)層，在Android中負(fù)責(zé)網(wǎng)絡(luò)請求和數(shù)據(jù)庫操作，并向外暴露接口。Controller是爭議比較多的寫法：一種是直接把Activity當(dāng)成Controller；一種是獨(dú)立出Controller類，進(jìn)行邏輯分離。比較符合MVC思想的筆者認(rèn)為是后者。因?yàn)榍罢咧苯釉贏ctivity中進(jìn)行書寫業(yè)務(wù)邏輯就會和UI邏輯混合在一起了，達(dá)不到模塊分工的效果。

優(yōu)點(diǎn)：簡單。他不需要寫很多的代碼來讓代碼解耦，這在小型項(xiàng)目非常有用。小型項(xiàng)目總體的代碼就不多，所以這樣可以提高開發(fā)效率。

缺點(diǎn)：

幾乎所有的業(yè)務(wù)邏輯代碼都在Controller中進(jìn)行，會導(dǎo)致非常臃腫，降低項(xiàng)目的可測試性與可維護(hù)性。

View直接持有Controller和Model實(shí)例，不同職責(zé)的代碼進(jìn)行耦合，導(dǎo)致代碼耦合性高，模塊分工不清晰。

改進(jìn)方向：

對模塊進(jìn)行更加徹底的分離，不要讓View和Model直接聯(lián)系。對Controller進(jìn)行減壓。

MVP

相比MVC，MVP的更加的完善。MVP全名是Model-View-Presenter。圖解如下：

0

• View：UI模塊，負(fù)責(zé)界面顯示和與用戶交匯。

• Presenter：負(fù)責(zé)業(yè)務(wù)邏輯，起著連接View和Model橋梁的作用。

• Model：專注于數(shù)據(jù)操作邏輯。

MVP 和 MVC 的區(qū)別很明顯就在這個Presenter中。為了解決MVC中代碼的耦合嚴(yán)重性，把業(yè)務(wù)邏輯都抽離到了Presenter中。這樣View和Model完全被隔離，實(shí)現(xiàn)了單向依賴，大大減少了耦合度。View和Prensenter之間通過接口來通信，只要定義好接口，那么團(tuán)隊(duì)可以合作同時開發(fā)不同的模塊，同時不同的模塊也可以進(jìn)行獨(dú)立測試。也因各模塊獨(dú)立了，所以要只要符合接口規(guī)范，即可做到動態(tài)更換模塊而不需要修改其他的模塊。

在Android中，需要讓Activity提供控件的更新接口，Prensenter提供業(yè)務(wù)邏輯接口，Activity持有Presenter的實(shí)例，Presenter持有Activity的弱引用（不用直接引用是為了避免內(nèi)存泄露），Activity直接調(diào)用Presenter的方法更新界面，Presenter去Model獲取數(shù)據(jù)之后，通過View的接口更新View。

0

不同的View可以通過實(shí)現(xiàn)相同的接口來共享Prensenter。Prensenter也可以通過實(shí)現(xiàn)接口來實(shí)現(xiàn)動態(tài)更換邏輯。Model是完全獨(dú)立開發(fā)的，向外暴露的方法參數(shù)中含有callBack參數(shù)，可以直接調(diào)用callBack進(jìn)行回調(diào)。

優(yōu)點(diǎn)：

• MVP通過模塊職責(zé)分工，抽離業(yè)務(wù)邏輯，降低代碼的耦合性

• 實(shí)現(xiàn)模塊間的單向依賴，代碼思路清晰，提高可維護(hù)性

• 模塊間通過接口進(jìn)行通信，降低了模塊間的耦合度，可以實(shí)現(xiàn)不同模塊獨(dú)立開發(fā)或動態(tài)更換

缺點(diǎn)：

• 過度設(shè)計導(dǎo)致接口過多，編寫大量的代碼來實(shí)現(xiàn)模塊解耦，降低了開發(fā)效率

• 并沒有徹底進(jìn)行解耦，Prensenter需要同時處理UI邏輯和業(yè)務(wù)邏輯，Prensenter臃腫

MVVM

MVVM和上面兩種架構(gòu)模式一樣都是一種架構(gòu)思想，只是谷歌推出了jetpack架構(gòu)組件來讓我們更好的使用這種架構(gòu)模式。

MVVM，全名為Model-View-ViewModel。

0

• View：和前面的MVP、MVC中的View一樣，負(fù)責(zé)UI界面的顯示以及與用戶的交匯。

• Model：同樣是負(fù)責(zé)網(wǎng)絡(luò)數(shù)據(jù)獲取或者本地數(shù)據(jù)庫數(shù)據(jù)獲取。

• ViewModel：負(fù)責(zé)存儲View的數(shù)據(jù)映像以及業(yè)務(wù)邏輯。

MVVM的View和Model和前面的兩種架構(gòu)模式是差不多的，重點(diǎn)在ViewModel。ViewModel通過將數(shù)據(jù)和View進(jìn)行綁定，修改數(shù)據(jù)會直接反映到View上，通過數(shù)據(jù)驅(qū)動型思想，徹底把MVP中的Presenter的UI操作邏輯給去掉了。而ViewModel是綁定于單獨(dú)的View的，也就不需要進(jìn)行編寫接口了。但ViewModel中依舊有很多的業(yè)務(wù)邏輯，但是因?yàn)榘裋iew和數(shù)據(jù)進(jìn)行綁定，這樣可以讓View和業(yè)務(wù)徹底的解耦了。View可以專注于UI操作，而ViewModel可以專注于業(yè)務(wù)操作。因而MVVM通過數(shù)據(jù)驅(qū)動型思想，徹底把業(yè)務(wù)和UI邏輯進(jìn)行解耦，各模塊分工職責(zé)明確。

缺點(diǎn)：

MVVM的ViewModel依舊很臃腫。

MVVM需要學(xué)習(xí)數(shù)據(jù)綁定框架，具有一定的上手難度。

適合android開發(fā)的MVVM架構(gòu)模式：

0

簡單的解析：

View對應(yīng)的就是Activity和Fragment，在這里進(jìn)行UI操作。

ViewModel中包含了LiveData，這是一種可觀察數(shù)據(jù)類型框架。View通過向LiveData注冊觀察者，當(dāng)LiveData發(fā)生改變時，就會直接調(diào)用觀察者的邏輯把數(shù)據(jù)更新到View上。

ViewModel完全不需要關(guān)心UI操作，只需要專注于數(shù)據(jù)與業(yè)務(wù)操作。

Repository代表了Model層，Repository對ViewModel進(jìn)行了減壓，i把業(yè)務(wù)操作般到了Repository中，避免了ViewModel臃腫。

Repository對請求進(jìn)行判斷是要到本地數(shù)據(jù)庫獲取還是網(wǎng)絡(luò)請求獲取分別調(diào)用不同的模塊。