分層思想

分層是一種思想，同時(shí)也是一種架構(gòu)模式。它的特點(diǎn)是專職，即某一層的職責(zé)是相同的、確定的；比如我們平時(shí)所謂的Dao、Controller層…他們都有明確的職責(zé)。

分層架構(gòu)雖說不能完完全全的解決項(xiàng)目程序復(fù)雜度高的問題，但是通過分層，將大的問題抽象分解成了小的功能面，局部化在每一層中，這樣就有效的降低了單個(gè)問題的規(guī)模和復(fù)雜度；另外層與層之間也可以通過簡單的調(diào)整插入新的層面，用以滿足不斷變化的需求，同一層面來說也可近乎0成本的水平擴(kuò)展；并且易于Debug、測試。

什么是MVC/MVP ？

MVC實(shí)際上是一種分層思想的踐行者和改進(jìn)者，在GUI編程中，MVC已經(jīng)有幾十年的歷史了。
顧名思義M(Model)即數(shù)據(jù)模型層，Model層很有意思，對于服務(wù)端編程來說我們把MVC中的M極有可能是包括了業(yè)務(wù)處理(Service)和實(shí)體類的，對于客戶端編程來說MVC中的M可能就僅僅是數(shù)據(jù)模型，當(dāng)然以上的說法只是于我個(gè)人而言的體會，不代表廣義立場。
V(View)即視圖層/表現(xiàn)層，主要負(fù)責(zé)數(shù)據(jù)的展示和用戶的交互，C(Controller)即控制層，主要負(fù)責(zé)一些數(shù)據(jù)傳遞、請求轉(zhuǎn)發(fā)、業(yè)務(wù)處理的委派。
以上是標(biāo)準(zhǔn)意義上的MVC，對于Android來說：
Model：數(shù)據(jù)模型(實(shí)體類、持久化、IO)
View：布局文件
Controller：對應(yīng)于Activity、Fragment，包含一些業(yè)務(wù)邏輯的處理
這里我們會發(fā)現(xiàn)，Android的MVC事實(shí)上V層的職責(zé)一部分被C層承擔(dān)了，比如一些交互我們必須寫到Activity/Fragment中，這樣就會導(dǎo)致C層既包含UI操作，又有網(wǎng)絡(luò)請求、業(yè)務(wù)處理等；導(dǎo)致C層過于臃腫，不利于項(xiàng)目后期的維護(hù)和擴(kuò)展。

所以，MVP就應(yīng)運(yùn)而生了，MVP實(shí)際上是由MVC進(jìn)化而來，它比較好的解決了MVC時(shí)代遺留的問題，MVP中的各層含義：
Model：數(shù)據(jù)模型(實(shí)體類、持久化、IO)
View：Activity/Fragment和布局文件
Presenter：負(fù)責(zé)完成View和Model之間的交互和業(yè)務(wù)邏輯
其核心是：設(shè)計(jì)一個(gè)抽象的V層接口，并由具體的View實(shí)現(xiàn)該接口，P層內(nèi)部維護(hù)一個(gè)該接口的實(shí)例引用，一般在構(gòu)造函數(shù)中傳遞進(jìn)來復(fù)制(即View層初始化P層實(shí)例時(shí))，彼時(shí)P層即可通過調(diào)用該接口來完成對View層的操作,V層也因持有P層實(shí)例，可以進(jìn)行業(yè)務(wù)邏輯處理委派。

MVVM是什么，與MVC/MVP有何區(qū)別 ？

MVVM是對MVP/MVC的一種改進(jìn)，既解決了MVC時(shí)代的職責(zé)不明的問題，也很好的解決了MVP模式中需要編寫過多繁瑣的接口，以及V層和P層互相依賴所產(chǎn)生的一些隱式問題。

在MVVM中，各層含義如下
Model：數(shù)據(jù)模型(實(shí)體類、持久化、IO)
View：Activity/Fragment和布局文件
ViewModel：業(yè)務(wù)邏輯的處理、數(shù)據(jù)的轉(zhuǎn)換、連接M層和V層的橋梁
看上去似乎和MVP中各層的職責(zé)是類似的，并沒有顯著的不同和改進(jìn)；那么我們?yōu)楹我褂肕VVM架構(gòu)呢？

• 雙向綁定、數(shù)據(jù)驅(qū)動
  在常規(guī)的開發(fā)模式中，數(shù)據(jù)變化需要更新UI的時(shí)候，需要先獲取UI控件的引用，然后再更新UI。獲取用戶的輸入和操作也需要通過UI控件的引用。在MVVM中，這些都是通過數(shù)據(jù)驅(qū)動來自動完成的，數(shù)據(jù)變化后會自動更新UI，UI的改變也能自動反饋到數(shù)據(jù)層，數(shù)據(jù)成為主導(dǎo)因素。這樣MVVM層在業(yè)務(wù)邏輯處理中只要關(guān)心數(shù)據(jù)，不需要直接和UI打交道，在業(yè)務(wù)處理過程中簡單方便很多。

• 高度解耦
  MVVM模式中，數(shù)據(jù)是獨(dú)立于UI的。
  數(shù)據(jù)和業(yè)務(wù)邏輯處于一個(gè)獨(dú)立的ViewModel中，ViewModel只需要關(guān)注數(shù)據(jù)和業(yè)務(wù)邏輯，不需要和UI或者控件打交道。UI想怎么處理數(shù)據(jù)都由UI自己決定，ViewModel不涉及任何和UI相關(guān)的事，也不持有UI控件的引用。即便是控件改變了（比如：TextView換成EditText），ViewModel也幾乎不需要更改任何代碼。它非常完美的解耦了View層和ViewModel，解決了上面我們所說的MVP的痛點(diǎn)。

• 可復(fù)用、易測試、方便協(xié)同開發(fā)
  一個(gè)ViewModel可以復(fù)用到多個(gè)View中。同樣的一份數(shù)據(jù)，可以提供給不同的UI去做展示。對于版本迭代中頻繁的UI改動，更新或新增一套View即可。如果想在UI上做A/B Testing，那MVVM是你不二選擇。
  MVVM的分工是非常明顯的，由于View和ViewModel之間是松散耦合的：一個(gè)是處理業(yè)務(wù)和數(shù)據(jù)、一個(gè)是專門的UI處理。所以，完全由兩個(gè)人分工來做，一個(gè)做UI（XML和Activity）一個(gè)寫ViewModel，效率更高
  ViewModel層做的事是數(shù)據(jù)處理和業(yè)務(wù)邏輯，View層中關(guān)注的是UI，兩者完全沒有依賴。不管是UI的單元測試還是業(yè)務(wù)邏輯的單元測試，都是低耦合的。在MVVM中數(shù)據(jù)是直接綁定到UI控件上的（部分?jǐn)?shù)據(jù)是可以直接反映出UI上的內(nèi)容），那么我們就可以直接通過修改綁定的數(shù)據(jù)源來間接做一些Android UI上的測試。

Android Architecture Components(架構(gòu)組件)

實(shí)現(xiàn)MVVM的方式和工具有很多，既可以使用Google在2015年推出的DataBinding庫，亦或是其他。也可以選擇Google IO 2017 推出的Android Architecture Components即架構(gòu)組件，這也是本文所采用的解決方案。

包含以下組件：

• 生命周期管理庫 - Lifecycle
  • Lifecycle組件，為下面兩個(gè)組件提供了生命周期感知的基礎(chǔ)
  • LiveData組件，可觀測的、可感知生命周期的數(shù)據(jù)
  • ViewModel組件，不依賴于View、提供UI數(shù)據(jù)、橋接持久層、業(yè)務(wù)邏輯
• 數(shù)據(jù)持久化庫 - Room，Sqlite的ORM
  事實(shí)上，Architecture Components實(shí)現(xiàn)了一個(gè)比較理想化的依賴方式，自上而下，單項(xiàng)依賴；VM層并不持有View層的任何引用，但卻是生命周期感知的，在新版的AS中View也不用去實(shí)現(xiàn)某些接口或繼承特定的類，AppCompatActivity已經(jīng)幫你整合了這一切。另外，關(guān)于Repository的解釋，它并不是架構(gòu)組件的成員，但是Google推薦引用Repository層，來作為我們唯一的數(shù)據(jù)來源接口，我們從圖中也很好理解，他的職責(zé)就是使VM層對數(shù)據(jù)來源是無感知的，包裝了數(shù)據(jù)來源，提供統(tǒng)一的API，供上層透明化的調(diào)用。
  demo下期提供 到此為止。告辭