MVC与MVP比较

MVC_MVP.png

相同点：

• View：Activity&Fragment(为省事后文只说Activity啦) + layout xml，职责是显示信息和响应用户操作；
• Model：提供数据的增删改查操作，并通过回调方法把结果反馈出去；数据位置是抽象过的，可能在本地或远程

不同点：

MVC模式

Activity还担当了Controller角色，这样职责又再增加：执行业务逻辑、调用Model操作数据以及把操作结果更新到界面上。

Activity=View+Controller，带来的问题：

• 违背单一职责原则，界面操作和业务逻辑混在一起；
• 业务逻辑原本是与平台无关的抽象，现在和安卓界面捆在一起，没法单元测试了

太Low了，让Presenter来主持大局吧

MVP模式：新增Presenter

• 职责：体现抽象的业务逻辑、调用Model操纵数据、调用View刷新显示和展示信息、响应用户操作

• Activity的Controler职责废除，由Presenter接手

  Activity大大简化

           1) 只由Presenter派活儿，被动显示信息
  
           2) 用户操作直接传递给Presenter处理
  
           3)与Model断交，两者互不相认
  

MVPArms架构实践

问题.Presenter怎么依赖View和Model

Presenter是平台无关的，是抽象的，View和Model是平台相关的，是具体的；既然不能直接依赖，那就需要把View和Model抽象为接口；

google官方todo-mvp是提供一个Contract接口，包含View和Presenter子接口

MVPArms的做法是在Contract接口中包含View和Model子接口；

至于Presenter是否需要抽取为接口，网上颇有争论，后文再聊

问题.类太多啦

嗯，让我们算一下有哪些类和接口

类：Activity, Presenter, Model,

接口：Contract(View、Model)

再加上Dagger需要的Module, Component；吓死宝宝了！

类多对这个问题要理性看待，只要职责清晰不重复，从解耦角度看反而是正面的，不是问题；

当然人都是懒的，工作量太多了怎么办？MVPArms模板出动，全家桶一次创建好

问题：职责细分后对象间的依赖怎么办？让Dagger来

原本Activity的一大块工作，现在被Presenter承包了，起码要创建Presenter吧，此外Presenter和Model也是需要资源才能干活的，比如：application context，adapter等等，这样多出了这些事情要做：

• activity中创建new presenter，presenter中创建model

• presenter增加setXXX，setYYY, setZZZ，给activity调用以传递资源

• model可能也要增加setXXX,setYYY，给presenter调用；

  一堆无聊的代码！

  你会说不用啊，大部分资源都是全局的，做成单例直接XXX.getInstance就行了，但还是有很多资源不是单例的，而且本身单例模式对单元测试就不友好。

  好了，该Dagger登场了，不用再手工创建presenter，也不用setXXX了，全局资源也不用写成单例了，标注为@Singleton再通过AppComponent注入就行

  不过Dagger这货确实不直观，需要挺多学习成本，但是值得。

  Dagger解惑

• DI容器和入口

  activity,fragment和Application是常用的DI容器。注入入口是：

  DaggerUserComponent.builder()
                  .appComponent(appComponent) // MVPArms在此处传入App全局依赖
                  .userModule(new UserModule(this))
                  .build()
                  .inject(this);
  

  这句调用完以后，带有@Inject注解的字段(Presenter、Model、Adapter等)都会被赋值；

• Scope和单例生命周期:

  普通单例同类的static变量引用，即一个进程中只有一个单例对象；

如果把普通单例说成是全局单例，则dagger Scope修饰出来的单例，是局部单例。

对，这几个Scope作用没有区别，一毛一样：@Singleton @Activity @Fragment

至于被Scope修饰实例的生命周期，则跟随其所属Component：

• Component在activity,fragment中创建：生命周期和activity,fragment一样
• Component在Application中创建：生命周期和app一样长

RxJava:遇见更好的Model

Model的方法举例，调用者是P层：

// 不采用RxJava
void getUser(int idStart, int count, Callback<List<User>> resultCallback);

// 采用RxJava
Observable<List<User>> getUser(int idStart, int count);

采用RxJava后，返回值变为Obserable<XXX>，由于Obserable天然的数据流属性，带来了以下好处：

• 不用Callback了，P层subscribe就行

• 返回值更直观，一目了然

• Obserable可以自如的切换线程，这样可以把切换线程操作放到P层，Model层方法更简洁

• Obserable可以进行灵活的变换操作，比如

  • 如果网络返回值是包装过的，而非直接是一个List<User>时，可以做map变换，取出map

  • 如果网络报错提示token过期，可以做flatMap变换，插入一个login，然后再次getUser

    这两种情况用传统Callback方式也能搞定，但嵌套callback远不如Rx分步流水线优雅

RxJava 结合Model场景

• 网络

  必须是retrofit了，带上RxJavaCallAdapter；

  再加上RxCache，则一并搞定缓存读写，RxCache是挺方便的，但功能并不全面，比如要强制读缓存就不行，需要二次开发

• 数据库

  这部分MVPArms没有封装；能想到的理想方案是RxJava结合Room，等到有实践再经验再补充；

让Presenter和Model感知ActivityLifeCycle

使用 2017 Google IO 发布的 Architecture Components 中的 Lifecycles 的新特性 (此特性已被加入 Support library)，使Presenter和Model可以感知SupportActivity和Fragment的生命周期；

MVPArms 怎么做到的，上Code:

public class BasePresenter<M extends IModel, V extends IView> 
                            implements IPresenter, LifecycleObserver {
@Override
    public void onStart() {
        //将 LifecycleObserver 注册给 LifecycleOwner 后 @OnLifecycleEvent 才可以正常使用
        if (mRootView != null && mRootView instanceof LifecycleOwner) {
          ((LifecycleOwner) mRootView).getLifecycle().addObserver(this);
          if (mModel!= null && mModel instanceof LifecycleObserver){
              ((LifecycleOwner) mRootView).getLifecycle().addObserver((LifecycleObserver) mModel);
            }
        }
    }

这样Presenter可以主动执行操作，不需要通过Activity来启动了，比如：

@OnLifecycleEvent(Lifecycle.Event.ON_CREATE)
void onCreate() {   
    requestUsers(true);//打开 App 时自动加载列表
}

这段代码是在Activity.onCreate()后面执行

Contact中是否要写Presenter接口

这个问题存在争论，google todo-mvp-exmaple是写了P接口的；

Contract中包含MVP三个接口，看起来是比较清晰了，但在MVPArms框架中，P接口没有必要存在：

• 没有任何地方需要用到，P接口存在反而会让人迷惑：Activity类的Presenter泛型参数到底填P接口还是P类呢，实际填P接口会导致BaseActivity的mPresenter对象Dagger编译报告MissBinding；既然这么尴尬，还是不要写P接口了吧
• 另一个不写P接口的理由是：Activity所依赖的P已经是抽象的业务逻辑了，没有必要再多做抽象

认为要写P接口的人，一般都用这个理由：看起来P暴露给View的接口方法更清晰。

能懒则懒，我喜欢不写。

其它问题

• Presenter重用问题

  参考：https://github.com/JessYanCoding/MVPArms/issues/181