MVVM_Android-CleanArchitecture

原文发表于：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 放出正式版了。

分层架构与 M-V-X

首先仍是先来讲说 分层架构 与 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）的应用。这些软件工程理论的东西就这样了，都是大师们留下来的东西，不要随便套上本身的概念。

Android-CleanArchitecture

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

自带 Dagger 信仰光环者障眼之术开启， 哈哈，大家看不到接下来的这句话了。。我如今也是持不同意 di 的观点的人(在 Android 中、、、)，能够看看这场撕逼：依赖注入是否值得？。结果就是我把原项目的依赖注入模块去掉了，对于测试中的类中的成员变量来讲原本就是 Mock 抽象接口，那就直接对接口或抽象类直接 Mock 操做就可，毕竟依赖注入的解耦依然是取决于须要注入的对象的抽象，维护依赖注入模块（Module）也是负担，测试代码中又要多写一套注入控制的 Dagger Module 代码。。

RxJava、RxAndroid

先说 AsyncTask，对其已经再也不想吐槽，这么重要的异步实现，版本间（Android Api）代码改来改去，又顺序又无序、又单线程执行又并发执行、内存泄露、、、。因此对于采用 RxJava 即便不采用函数响应式编程的大概念，用它来替换 AsyncTask 和 Thread + Handler 也是推荐的。此外使用 Rx 后也不须要事件总线的框架了，对于回调监听直接在数据操做的 Observable 上注册观察者便可，相对于事件总线来讲是更精准的（单线）的监听。而事件总线的话则是更加松耦合的，出错的话会更加难排查，这里就再也不展开了。

Lambda

我的、团队喜爱，代码简洁了不少可是代码的逻辑比较很差直观理解了，原项目也只有 3 处代码用到，故而去掉了。

此外，对于领域驱动设计（DDD）中 Repository，原项目中把其实现放到了 data 层去实现（接口），形成 data 层会依赖其上一层（domain 业务层），做为分层架构我的认为不合适因此从新把它调整了。根据 DDD，我的认为 Repository 它的存在让领域层（domain 业务）感受不到数据访问层的存在，它提供一个相似集合的接口提供给领域层进行领域对象的访问。Repository 是仓库管理员，领域层须要什么东西只需告诉仓库管理员，由仓库管理员把东西拿给它，并不须要知道东西实际放在哪。

MVVM

理论简述

按照常理，先来讲基本概念：

• Model，domain model（领域模型）或是数据层表明的数据模型，也能够理解为用户界面须要显示数据的抽象（数据）

• View， 应用的界面

• ViewModel，binder 所在之处，是 View 的抽象，对外暴露出公共属性和命令，是 View 与 Model 的（绑定）链接器

此外还有必不可少的一部分：Binder，Android 中也就是 Data binding 了，提供 View 与 Model 的绑定功能。下面是结构图：

Android 中实现

目前 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<VM extends ViewModel, B extends ViewDataBinding> 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：
  

Refactor

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

须要注意的是 include 标签的 XML 节点中要使用到根节点中 data 标签里设置的 viewModel variable 的话须要这样设置；

<include
      layout="@layout/view_retry"
      bind:viewModel="@{viewModel}"/>

抽象类 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!

END

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