前言

當(dāng)我們接手一個項目的時候，經(jīng)常會發(fā)現(xiàn)一個activity或fragment動輒上千行甚至上萬行代碼，這給閱讀帶來很大的困擾，如果想讀懂代碼，需要花費很多時間跟精力。引起這個問題的原因想必大家都了解，隨著人員不斷變動，需求不斷增多，在沒有嚴(yán)格代碼規(guī)范的前提下，每個人都是根據(jù)自己的偏好把需求做完，最后是代碼越堆越多，維護性越來越差。為什么大家都喜歡往activity里面堆代碼呢？究其原因，是因為android里面xml視圖功能太弱，activity不僅要承擔(dān)視圖顯示，還要加入控制邏輯，承擔(dān)太多職責(zé)，代碼就會越堆越多。

在MVC之前，有些人會考慮把activity的控制邏輯抽成Manager，但是也沒有一致的規(guī)范標(biāo)準(zhǔn)，只是讓代碼看著清爽了些，并沒有從本質(zhì)上把問題解決掉，也就是View層跟controller層并未解耦。為了解決這個問題，MVP出現(xiàn)了，雖然可以代替activity處理大部分控制邏輯，但是MVP也存在瑕疵，代碼量變大，接口變多等，因為Presenter要持有view的引用，感覺兩者并未完全解耦。此時MVVM出現(xiàn)了，好像就是為了完善MVP的不足而設(shè)計的，在這種模式下，viewmodle跟view之間的交互是通過Data Binding來完成的，Data Binding可以實現(xiàn)雙向的交互，這就使得視圖跟控制層之間的耦合度進(jìn)一步降低。

一. MVC

Model-View-Controller.png

MVC全稱Model View Controller,如上圖,是模型(model)-視圖(view)-控制器(controller)的縮寫,用一種業(yè)務(wù)邏輯、數(shù)據(jù)、界面顯示分離的方法組織代碼。

其中M層處理數(shù)據(jù),業(yè)務(wù)邏輯等;V層處理界面的顯示結(jié)果;C層起到橋梁的作用,來控制V層和M層通信以此來達(dá)到分離視圖顯示和業(yè)務(wù)邏輯層。

Android中界面部分也采用了當(dāng)前比較流行的MVC框架,在Android中:

視圖層(View)

一般采用XML文件進(jìn)行界面的描述,這些XML可以理解為AndroidApp的View。使用的時候可以非常方便的引入。同時便于后期界面的修改。邏輯中與界面對應(yīng)的id不變化則代碼不用修改,大大增強了代碼的可維護性。

控制層(Controller)

Android的控制層的重任通常落在了眾多的Activity的肩上。這句話也就暗含了不要在Activity中寫代碼,要通過Activity交割Model業(yè)務(wù)邏輯層處理,這樣做的另外一個原因是Android中的Actiivity的響應(yīng)時間是5s,如果耗時的操作放在這里,程序就很容易被回收掉。

模型層(Model)

我們針對業(yè)務(wù)模型,建立的數(shù)據(jù)結(jié)構(gòu)和相關(guān)的類,就可以理解為AndroidApp的Model,Model是與View無關(guān),而與業(yè)務(wù)相關(guān)的。對數(shù)據(jù)庫的操作、對網(wǎng)絡(luò)等的操作都應(yīng)該在Model里面處理,當(dāng)然對業(yè)務(wù)計算等操作也是必須放在的該層的。就是應(yīng)用程序中二進(jìn)制的數(shù)據(jù)。

一. MVP

Model-View-Presenter.png

MVP框架由3部分組成:View負(fù)責(zé)顯示,Presenter負(fù)責(zé)邏輯處理,Model提供數(shù)據(jù)。在MVP模式里通常包含3個要素(加上View interface是4個):

View

負(fù)責(zé)繪制UI元素、與用戶進(jìn)行交互(在Android中體現(xiàn)為Activity)

Model

負(fù)責(zé)存儲、檢索、操縱數(shù)據(jù)(有時也實現(xiàn)一個Model interface用來降低耦合)

Presenter

作為View與Model交互的中間紐帶,處理與用戶交互的負(fù)責(zé)邏輯。

因此我們可以發(fā)現(xiàn)MVP的優(yōu)點如下:

1、模型與視圖完全分離,我們可以修改視圖而不影響模型;

2、可以更高效地使用模型,因為所有的交互都發(fā)生在一個地方——Presenter內(nèi)部;

3、我們可以將一個Presenter用于多個視圖,而不需要改變Presenter的邏輯。這個特性非常的有用,因為視圖的變化總是比模型的變化頻繁;

4、如果我們把邏輯放在Presenter中,那么我們就可以脫離用戶接口來測試這些邏輯(單元測試)。

一. MVVM

Model-View-ViewModel.png

View

View層做的就是和UI相關(guān)的工作，我們只在XML和Activity或Fragment寫View層的代碼，View層不做和業(yè)務(wù)相關(guān)的事，也就是我們的Activity 不寫和業(yè)務(wù)邏輯相關(guān)代碼，也不寫需要根據(jù)業(yè)務(wù)邏輯來更新UI的代碼，因為更新UI通過Binding實現(xiàn)，更新UI在ViewModel里面做(更新綁定的數(shù)據(jù)源即可)，Activity 要做的事就是初始化一些控件(如控件的顏色，添加 RecyclerView 的分割線)，Activity可以更新UI，但是更新的UI必須和業(yè)務(wù)邏輯和數(shù)據(jù)是沒有關(guān)系的，只是單純的根據(jù)點擊或者滑動等事件更新UI(如 根據(jù)滑動顏色漸變、根據(jù)點擊隱藏等單純UI邏輯)，Activity(View層)是可以處理UI事件，但是處理的只是處理UI自己的事情，View層只處理View層的事。簡單的說：View層不做任何業(yè)務(wù)邏輯、不涉及操作數(shù)據(jù)、不處理數(shù)據(jù)、UI和數(shù)據(jù)嚴(yán)格的分開。

ViewModel

ViewModel層做的事情剛好和View層相反，ViewModel 只做和業(yè)務(wù)邏輯和業(yè)務(wù)數(shù)據(jù)相關(guān)的事，不做任何和UI、控件相關(guān)的事，ViewModel 層不會持有任何控件的引用，更不會在ViewModel中通過UI控件的引用去做更新UI的事情。ViewModel就是專注于業(yè)務(wù)的邏輯處理，操作的也都是對數(shù)據(jù)進(jìn)行操作，這些個數(shù)據(jù)源綁定在相應(yīng)的控件上會自動去更改UI，開發(fā)者不需要關(guān)心更新UI的事情。關(guān)于對UI控件事件的處理，我們也希望能把這些事件處理綁定到控件上，并把這些事件統(tǒng)一化，方便ViewModel對事件的處理和代碼的美觀。為此我們通過BindingAdapter 對一些常用的事件做了封裝，把一個個事件封裝成一個個Command，對于每個事件我們用一個ReplyCommand去處理就行了,ReplyCommand會把可能你需要的數(shù)據(jù)帶給你，這使得我們處理事件的時候也只關(guān)心處理數(shù)據(jù)就行了，再強調(diào)一遍ViewModel 不做和UI相關(guān)的事。

Model

Model 的職責(zé)很簡單，基本就是實體模型(Bean)同時包括Retrofit 的Service ，ViewModel 可以根據(jù)Model 獲取一個Bean的Observable( RxJava ),然后做一些數(shù)據(jù)轉(zhuǎn)換操作和映射到ViewModel 中的一些字段，最后把這些字段綁定到View層上。 上面三部分的分工很明確，要不要把一部分邏輯放到activity 或者fragment來做是取決于你的提到的操作邏輯是什么，如果這些邏輯操作是可以通過修改數(shù)據(jù)(這些數(shù)據(jù)綁定到UI)來更改UI或者你的操作邏輯是業(yè)務(wù)邏輯或者修改數(shù)據(jù)，那么這塊邏輯你完全可以在ViewModel 里面做。如果這些邏輯操作只是和UI有關(guān)，而且不能通過Binding的方式更改數(shù)據(jù)源去反饋到UI(比如說 簡單的對話框、PopupWindow等)是可以考慮放到View層去做，但是如果這部分操作邏輯涉及到業(yè)務(wù)和數(shù)據(jù)相關(guān)的，那么建議不用放到View層做，View層主要職責(zé)是和UI相關(guān)的、沒有數(shù)據(jù)，沒有業(yè)務(wù)。

PS:該文章僅供自己學(xué)習(xí)之用！

總結(jié)

以上是生活随笔為你收集整理的android mvc mvp 简书,浅析 MVP,MVC,MVVM模式(Android)的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。