android mvc mvp 简书,浅析 MVP,MVC,MVVM模式(Android)
前言
當我們接手一個項目的時候，經常會發現一個activity或fragment動輒上千行甚至上萬行代碼，這給閱讀帶來很大的困擾，如果想讀懂代碼，需要花費很多時間跟精力。引起這個問題的原因想必大家都了解，隨著人員不斷變動，需求不斷增多，在沒有嚴格代碼規范的前提下，每個人都是根據自己的偏好把需求做完，最后是代碼越堆越多，維護性越來越差。為什么大家都喜歡往activity里面堆代碼呢？究其原因，是因為android里面xml視圖功能太弱，activity不僅要承擔視圖顯示，還要加入控制邏輯，承擔太多職責，代碼就會越堆越多。
在MVC之前，有些人會考慮把activity的控制邏輯抽成Manager，但是也沒有一致的規范標準，只是讓代碼看著清爽了些，并沒有從本質上把問題解決掉，也就是View層跟controller層并未解耦。為了解決這個問題，MVP出現了，雖然可以代替activity處理大部分控制邏輯，但是MVP也存在瑕疵，代碼量變大，接口變多等，因為Presenter要持有view的引用，感覺兩者并未完全解耦。此時MVVM出現了，好像就是為了完善MVP的不足而設計的，在這種模式下，viewmodle跟view之間的交互是通過Data Binding來完成的，Data Binding可以實現雙向的交互，這就使得視圖跟控制層之間的耦合度進一步降低。
一. MVC
Model-View-Controller.png
MVC全稱Model View Controller,如上圖,是模型(model)-視圖(view)-控制器(controller)的縮寫,用一種業務邏輯、數據、界面顯示分離的方法組織代碼。
其中M層處理數據,業務邏輯等;V層處理界面的顯示結果;C層起到橋梁的作用,來控制V層和M層通信以此來達到分離視圖顯示和業務邏輯層。
Android中界面部分也采用了當前比較流行的MVC框架,在Android中:
視圖層(View)
一般采用XML文件進行界面的描述,這些XML可以理解為AndroidApp的View。使用的時候可以非常方便的引入。同時便于后期界面的修改。邏輯中與界面對應的id不變化則代碼不用修改,大大增強了代碼的可維護性。
控制層(Controller)
Android的控制層的重任通常落在了眾多的Activity的肩上。這句話也就暗含了不要在Activity中寫代碼,要通過Activity交割Model業務邏輯層處理,這樣做的另外一個原因是Android中的Actiivity的響應時間是5s,如果耗時的操作放在這里,程序就很容易被回收掉。
模型層(Model)
我們針對業務模型,建立的數據結構和相關的類,就可以理解為AndroidApp的Model,Model是與View無關,而與業務相關的。對數據庫的操作、對網絡等的操作都應該在Model里面處理,當然對業務計算等操作也是必須放在的該層的。就是應用程序中二進制的數據。
一. MVP
Model-View-Presenter.png
MVP框架由3部分組成:View負責顯示,Presenter負責邏輯處理,Model提供數據。在MVP模式里通常包含3個要素(加上View interface是4個):
View
負責繪制UI元素、與用戶進行交互(在Android中體現為Activity)
Model
負責存儲、檢索、操縱數據(有時也實現一個Model interface用來降低耦合)
Presenter
作為View與Model交互的中間紐帶,處理與用戶交互的負責邏輯。
因此我們可以發現MVP的優點如下:
1、模型與視圖完全分離,我們可以修改視圖而不影響模型;
2、可以更高效地使用模型,因為所有的交互都發生在一個地方——Presenter內部;
3、我們可以將一個Presenter用于多個視圖,而不需要改變Presenter的邏輯。這個特性非常的有用,因為視圖的變化總是比模型的變化頻繁;
4、如果我們把邏輯放在Presenter中,那么我們就可以脫離用戶接口來測試這些邏輯(單元測試)。
一. MVVM
Model-View-ViewModel.png
View
View層做的就是和UI相關的工作，我們只在XML和Activity或Fragment寫View層的代碼，View層不做和業務相關的事，也就是我們的Activity 不寫和業務邏輯相關代碼，也不寫需要根據業務邏輯來更新UI的代碼，因為更新UI通過Binding實現，更新UI在ViewModel里面做(更新綁定的數據源即可)，Activity 要做的事就是初始化一些控件(如控件的顏色，添加 RecyclerView 的分割線)，Activity可以更新UI，但是更新的UI必須和業務邏輯和數據是沒有關系的，只是單純的根據點擊或者滑動等事件更新UI(如 根據滑動顏色漸變、根據點擊隱藏等單純UI邏輯)，Activity(View層)是可以處理UI事件，但是處理的只是處理UI自己的事情，View層只處理View層的事。簡單的說：View層不做任何業務邏輯、不涉及操作數據、不處理數據、UI和數據嚴格的分開。
ViewModel
ViewModel層做的事情剛好和View層相反，ViewModel 只做和業務邏輯和業務數據相關的事，不做任何和UI、控件相關的事，ViewModel 層不會持有任何控件的引用，更不會在ViewModel中通過UI控件的引用去做更新UI的事情。ViewModel就是專注于業務的邏輯處理，操作的也都是對數據進行操作，這些個數據源綁定在相應的控件上會自動去更改UI，開發者不需要關心更新UI的事情。關于對UI控件事件的處理，我們也希望能把這些事件處理綁定到控件上，并把這些事件統一化，方便ViewModel對事件的處理和代碼的美觀。為此我們通過BindingAdapter 對一些常用的事件做了封裝，把一個個事件封裝成一個個Command，對于每個事件我們用一個ReplyCommand去處理就行了,ReplyCommand會把可能你需要的數據帶給你，這使得我們處理事件的時候也只關心處理數據就行了，再強調一遍ViewModel 不做和UI相關的事。
Model
Model 的職責很簡單，基本就是實體模型(Bean)同時包括Retrofit 的Service ，ViewModel 可以根據Model 獲取一個Bean的Observable( RxJava ),然后做一些數據轉換操作和映射到ViewModel 中的一些字段，最后把這些字段綁定到View層上。 上面三部分的分工很明確，要不要把一部分邏輯放到activity 或者fragment來做是取決于你的提到的操作邏輯是什么，如果這些邏輯操作是可以通過修改數據(這些數據綁定到UI)來更改UI或者你的操作邏輯是業務邏輯或者修改數據，那么這塊邏輯你完全可以在ViewModel 里面做。如果這些邏輯操作只是和UI有關，而且不能通過Binding的方式更改數據源去反饋到UI(比如說 簡單的對話框、PopupWindow等)是可以考慮放到View層去做，但是如果這部分操作邏輯涉及到業務和數據相關的，那么建議不用放到View層做，View層主要職責是和UI相關的、沒有數據，沒有業務。
PS:該文章僅供自己學習之用！
總結
以上是生活随笔為你收集整理的android mvc mvp 简书,浅析 MVP,MVC,MVVM模式(Android)的全部內容，希望文章能夠幫你解決所遇到的問題。
