MVC架構

MVC架構模式最初生根于服務器端的Web開發(fā)，后來漸漸能夠勝任客戶端Web開發(fā)，再后來因Android項目由XML和Activity/Fragment組成,慢慢的Android開發(fā)者開始使用類似MVC的架構模式開發(fā)應用.

M層:模型層(model),主要是實體類,數(shù)據(jù)庫,網(wǎng)絡等存在的層面,model將新的數(shù)據(jù)發(fā)送到view層,用戶得到數(shù)據(jù)響應.

V層:視圖層(view),一般指XML為代表的視圖界面.顯示來源于model層的數(shù)據(jù).用戶的點擊操作等事件從view層傳遞到controller層.

C層:控制層(controller),一般以Activity/Fragment為代表.C層主要是連接V層和M層的,C層收到V層發(fā)送過來的事件請求,從M層獲取數(shù)據(jù),展示給V層.

M層和V層有連接關系,而Activity有時候既充當了控制層又充當了視圖層,導致項目維護比較麻煩.

MVC架構優(yōu)缺點

A. 缺點

M層和V層有連接關系,沒有解耦,導致維護困難.

Activity/Fragment中的代碼過多,難以維護.

Activity中有很多關于視圖UI的顯示代碼菠净，因此View視圖和Activity控制器并不是完全分離的，當Activity類業(yè)務過多的時候，會變得難以管理和維護.尤其是當UI的狀態(tài)數(shù)據(jù)歼培，跟持久化的數(shù)據(jù)混雜在一起，變得極為混亂.

B. 優(yōu)點

控制層和View層都在Activity中進行操作茸塞，數(shù)據(jù)操作方便.

模塊職責劃分明確.主要劃分層M,V,C三個模塊.

MVP架構

MVP,即是Model,View,Presenter架構模式.看起來類似MVC,其實不然.從上圖能看到Model層和View層沒有相連接,完全解耦.

用戶觸碰界面觸發(fā)事件,View層把事件通知Presenter層,Presenter層通知Model層處理這個事件,Model層處理后把結(jié)果發(fā)送到Presenter層,Presenter層再通知View層,最后View層做出改變.這是一整套流程.

M層:模型層(Model),此層和MVC中的M層作用類似.

V層:視圖層(View),在MVC中V層只包含XML文件,而MVP中V層包含XML,Activity和Fragment三者.理論上V層不涉及任何邏輯,只負責界面的改變,盡量把邏輯處理放到M層.

P層:通知層(Presenter),P層的主要作用就是連接V層和M層,起到一個通知傳遞數(shù)據(jù)的作用.

?MVP架構優(yōu)缺點

A. 缺點

MVP中接口過多.

每一個功能,相比于MVC要多寫好幾個文件.

如果某一個界面中需要請求多個服務器接口,這個界面文件中會實現(xiàn)很多的回調(diào)接口,導致代碼繁雜.

如果更改了數(shù)據(jù)源和請求中參數(shù),會導致更多的代碼修改.

額外的代碼復雜度及學習成本.

B. 優(yōu)點

模塊職責劃分明顯,層次清晰,接口功能清晰.

Model層和View層分離,解耦.修改View而不影響Model.

功能復用度高,方便.一個Presenter可以復用于多個View,而不用更改Presenter的邏輯.

有利于測試驅(qū)動開發(fā),以前的Android開發(fā)是難以進行單元測試.

如果后臺接口還未寫好,但已知返回數(shù)據(jù)類型的情況下,完全可以寫出此接口完整的功能.

MVVM架構

v層：1).更新UI控件顯示躲庄，包括狀態(tài)及數(shù)據(jù)，由ViewModel驅(qū)動? 2).監(jiān)聽UI事件及其生命周期翔横，驅(qū)動ViewModel? 3).View層不直接處理任何業(yè)務邏輯及數(shù)據(jù)加工读跷。盡量做到瘦身，代碼邏輯簡約禾唁，減輕UI線程負擔效览。

ViewModel層：只做業(yè)務邏輯操作，不持有任何UI控件的引用

Model層：Model層就是數(shù)據(jù)層荡短。數(shù)據(jù)來源有：1).本地存儲數(shù)據(jù)丐枉，如數(shù)據(jù)庫，文件掘托，SharedPreferences（本質(zhì)也是文件）2).內(nèi)存的緩存或臨時數(shù)據(jù) 3).通過各種網(wǎng)絡協(xié)議獲取的遠程數(shù)據(jù)

通常View與ViewMode是雙向綁定的瘦锹，即View的改動會反饋到ViewModel，反之亦然闪盔。強調(diào)一點：上層只依賴臨近的下層弯院，下層不可調(diào)用上層

A.優(yōu)點.

雙向綁定技術，當Model變化時泪掀，View-Model會自動更新听绳，View也會自動變化。

由于控制器的功能大都移動到View上處理异赫，大大的對控制器進行了瘦身

View的功能進一步的強化椅挣，具有控制的部分功能头岔，若想無限增強它的功能，甚至控制器的全部功幾乎都可以遷移到各個View上（不過這樣不可取鼠证，那樣View干了不屬于它職責范圍的事情）

B.缺點

數(shù)據(jù)綁定使得 Bug 很難被調(diào)試

一個大的模塊中峡竣，model也會很大，雖然使用方便了也很容易保證了數(shù)據(jù)的一致性量九，當長期持有适掰，不釋放內(nèi)存，就造成了花費更多的內(nèi)存娩鹉。

數(shù)據(jù)雙向綁定不利于代碼重用