摘要：業務層，業務層，是最為核心的一層。對于和的狀態保存恢復也通過處理。對于的綁定操作和命令操作都是暴露的，也易于測試。需要注意的是標簽的節點中要使用到根節點中標簽里設置的的話需要這樣設置抽象類中設置了和注解，只起到清晰提醒作用。

原文發表于：Rocko"s blog(rocko.xyz)] - MVVM_Android-CleanArchitecture

"Architecture is About Intent, not Frameworks" - Robert C. Martin (Uncle Bob)

Uncle Bob 的這句話套在 MVVM 上也是適用的, MVVM 也僅僅是架構模式（Architectural pattern），其有一套自己的理論概念（pattern）而不是規定的具體實現（或 Frameworks）。早之前在知乎上相關問題的回答（android UI設計MVVM設計模式討論？）中也簡單提到過 MVVM 了，M-V-X 的關系如上圖，那么這一次博主把 Fernando Cejas(android10) 的 Android-CleanArchitecture 項目中的 MVP 實現重構成了用 MVVM 來實現。所以看這篇文章最好是先搞清了 Fernando Cejas(android10) 的 Android-CleanArchitecture sample app 和對應的兩篇文章（見參考）。整個歷程也算比較愉快，沒什么不良反應，這篇文章理所當然會重點說說 MVVM 的實現、 Data Binding 等相關的東西。那為什么擁抱 MVVM 呢。當然是 Google 推出官方的 data binding 啦，下一次的 Android MVVM 熱潮應該就是 data binding 放出正式版了。

首先還是先來說說 分層架構 與 MVC or M-V-X 之間的關系。分層架構是一種常見的軟件應用架構，在 Java 程序中可以算是一種應用標準了，通常又叫 N 層架構，而最常見的是 3 層架構，它包含如下 3 層：

展示層（Presentation tier），也稱為 UI 層，也就是程序的界面部分。

業務層（business logic(domain) tier）， 業務層，是最為核心的一層。

持久層（Data tier），數據持久層。

3 層架構是存在物理上分層概念的，從上往下即展示層、業務層、持久層，也從上往下由上一層依賴下一層。不同層之間也是 高內聚低耦合 的體現，層內高內聚，層間低耦合，層 是層內具體工作的高度抽象。低耦合則是依賴倒轉原則體現出來，高層依賴于下層的抽象而不是具體。

接下來先說 M-V-X 的鼻祖 MVC，Model–View–Controller (MVC) is a software architectural pattern for implementing user interfaces.，所以 MVC 模式是為用戶界面設計的，在 3 層架構中，MVC 是屬于展現層的部分，所以 MVVM 作為 MVC 的演進在與分層架構的關系上也是一樣。經常會看到 3 層架構與 M-V-X 混為一談的內容，這是不正確的，雖然都是 3 部分的內容但是不能 簡單地 把兩者的每一部分對應起來，我們應該理解為，在分層架構中 M-V-X 是在展示層（Presentation tier）的應用。這些軟件工程理論的東西就這樣了，都是大師們留下來的東西，不要隨便套上自己的概念。

Fernando Cejas(android10) 的 Android-CleanArchitecture 項目中也是采用典型的 3 層架構，其中 Presentation 展現層采用了 MVP 模式，如果還未了解過 MVP，可以看看我之前寫的文章：Android中的MVP。不過 Google 推出官方的 data binding 之后我覺得基本可以不用采用 MVP 了，在 M-V-X 中， MVP 與 MVVM 算是比較接近的了但 MVP 中的一堆 View 接口也是讓人頭疼的，而擁有 data binding 的 MVVM 則解決了這個問題，所以請大膽擁抱 MVVM。So，下面幾點是當中除 MVVM 外涉及到的東西，MVVM 放到下一節再講。

自帶 Dagger 信仰光環者障眼之術開啟， 哈哈，你們看不到接下來的這句話了。。我現在也是持不贊成 di 的觀點的人(在 Android 中、、、)，可以看看這場撕逼：依賴注入是否值得？。結果就是我把原項目的依賴注入模塊去掉了，對于測試中的類中的成員變量來說本來就是 Mock 抽象接口，那就直接對接口或抽象類直接 Mock 操作就可，畢竟依賴注入的解耦依然是取決于需要注入的對象的抽象，維護依賴注入模塊（Module）也是負擔，測試代碼中又要多寫一套注入控制的 Dagger Module 代碼。。

先說 AsyncTask，對其已經不再想吐槽，這么重要的異步實現，版本間（Android Api）代碼改來改去，又順序又無序、又單線程執行又并發執行、內存泄露、、、。所以對于采用 RxJava 即使不采用函數響應式編程的大概念，用它來替換 AsyncTask 和 Thread + Handler 也是推薦的。此外使用 Rx 后也不需要事件總線的框架了，對于回調監聽直接在數據操作的 Observable 上注冊觀察者即可，相對于事件總線來說是更精準的（單線）的監聽。而事件總線的話則是更加松耦合的，出錯的話會更加難排查，這里就不再展開了。

個人、團隊喜好，代碼簡潔了很多但是代碼的邏輯比較不好直觀理解了，原項目也只有 3 處代碼用到，故而去掉了。

此外，對于領域驅動設計（DDD）中 Repository，原項目中把其實現放到了 data 層去實現（接口），造成 data 層會依賴其上一層（domain 業務層），作為分層架構個人認為不合適所以重新把它調整了。根據 DDD，個人認為 Repository 它的存在讓領域層（domain 業務）感覺不到數據訪問層的存在，它提供一個類似集合的接口提供給領域層進行領域對象的訪問。Repository 是倉庫管理員，領域層需要什么東西只需告訴倉庫管理員，由倉庫管理員把東西拿給它，并不需要知道東西實際放在哪。

按照常理，先來說基本概念：

Model，domain model（領域模型）或是數據層代表的數據模型，也可以理解為用戶界面需要顯示數據的抽象（數據）

View， 應用的界面

ViewModel，binder 所在之處，是 View 的抽象，對外暴露出公共屬性和命令，是 View 與 Model 的（綁定）連接器

此外還有必不可少的一部分：Binder，Android 中也就是 Data binding 了，提供 View 與 Model 的綁定功能。下面是結構圖：

目前 Android 的 data binding 還是 beta，還只是 one-way 單向綁定，功能上還有所欠缺、控制性也還不強，但是把它寫出來還是沒問題的。對于 Activity、Fragment 而言僅僅是作為 Java View 看待，與 XML 對應，所以里面只有 View 的展現邏輯，此外沒有其它代碼。一個 Activity 或 Fragment（一般都 with XML） 對應一個 ViewModel，對于一個基礎 View（XML）可以通過繼承對應的 ViewModel 實現重用，本文的代碼也有體現。對于 Activity 和 Fragment 的View 狀態保存恢復也通過 ViewModel 處理。因為 binding 的入口在 Activity 或 Fragment 中，所以為了方便寫個基類處理 ViewModel 和 Binding 的初始化，然后在 對應的 XML 里加上 ViewModel 的 variable， XML 里不再有其它數據對象的 variable。

public abstract class BaseActivity extends Activity {

  private VM viewModel;
  private B binding;

  public void setViewModel(@NonNull VM viewModel) {
    this.viewModel = viewModel;
  }

  public VM getViewModel() {
    if (viewModel == null) {
      throw new NullPointerException("You should setViewModel first!");
    }
    return viewModel;
  }

  public void setBinding(@NonNull B binding) {
    this.binding = binding;
  }

  public B getBinding() {
    if (binding == null) {
      throw new NullPointerException("You should setBinding first!");
    }
    return binding;
  }

}

ViewModel 中通過 ObservableField 來達到細粒度的控制，綁定操作都放在 ViewModel 里，然后 ViewModel 里可以有多個 domain 中的 Interator(UseCase) 來得到 View 需要渲染的數據 Model。對于 ObservableField 的綁定操作和命令操作（Command）都是暴露的，也易于測試。binding 現在缺少手動在 Java 代碼中注冊通知事件的功能，比如有些 model 的渲染必須通過 Java 代碼來操作的話就需要了，在 Activity（Java View） 中通過向 Binding 注冊通知回調，而目前只能在 XML 中知道，當然目前也可以自己實現，方法也有多種：接口回調、EventBus、RxBus。。

除了 Persenter 改成 ViewModel 的邏輯、Repository 的抽象和具體都在 domain 外，其他部分基本一致，采用的測試也一致。

Clean Architecture：

MVVM_Clean-Architecture tier：

MVVM_Clean-Architecture put all：

Talk is cheap. Show you the code. ↓↓↓
MVVM_Android-CleanArchitecture

需要注意的是 include 標簽的 XML 節點中要使用到根節點中 data 標簽里設置的 viewModel variable 的話需要這樣設置；

抽象類 ViewModel 中設置了 @Command 和 @BindView 注解，只起到清晰提醒作用。

具體重構更改可以查看 commit 記錄：MVVM_Android-CleanArchitecture commits。可以看到 Activity 和 Fragment 的代碼是很清爽的，比 MVP 更清爽，因為 View 的數據渲染操作交給 binder 去處理了。對 Activity 或其對應界面進行 UI 測試的話，Mock 出 model 代表的數據然后傳遞給 ViewModel 中 @BindView 暴露出的方法，然后檢驗視圖對數據的正確顯示就行了，也就是 View 對 Model 做了正確的渲染。

企業應用架構模式
Architecting Android…The clean way? （Android-CleanArchitecture 的文章，譯文略）
Architecting Android…The evolution （Android-CleanArchitecture 的文章，譯文略）
Approaching Android with MVVM
ANDROID DATABINDING: GOODBYE PRESENTER, HELLO VIEWMODEL!

本文源碼：MVVM_Android-CleanArchitecture or Rocko-Android-Demo(-MVVM_Android-CleanArchitecture)