[源码]Android-Architecture及对MVP的理解

Android-Architecture是Google给出的MVP架构及其变种示例。各个分支代表了不同的架构。

• todo-mvp：原生态的MVP，其实就是说明了一下，在使用Fragment时MVP和Android组件是怎么对应的。

  • Model：纯Bean，既是View Model，又是Biz Model。Model不负责存取和转换逻辑
  • View：对应着Fragment和Android View，主要负责事件到Presenter函数的对应、原子化的显示功能。前者是Presenter接口的调用，后者是View为Presenter暴露的接口
  • Presenter：独立的类，主要提供简单的事件处理功能。
  • 这种方式，声明了View和Presenter的interface，通过这个隔离了实现。
  • 还有个比较好的方法来组织多层次的数据存储，使用同一个interface声明同一个TasksDataSource接口，不同的数据源各自实现内部逻辑。最后，Cache和调度由一个TasksRepository负责。Cache逻辑太简单，又有太多的各种更新逻辑，放到最高层，可以简化接口。

• todo-mvp-clean：clean-architecture的例子，基于MVP而来。clean本来就是要隔离系统的变化，所以对应关系更加脱离了Android系统

  • Entity（不变式）：对应了Model和接口，包括了Bean和MVP中的interface声明、DataSource声明
  • UseCase（功能）：对应了Presenter中独立存在的功能，可以看做使用Command模式抽象了一下Presenter的功能
  • Interface Adapters（粘合）：对应了Presenter的总体逻辑。相较于MVP中的Presenter，功能更加单一，没有了具体的业务逻辑
  • Frameworks&Drivers（外围）：View和Storage都可以算在这里面，跟runtime相关
  • 理解层面可以按上面总结，代码层面最大的变化其实就是Presenter又分了一层

• todo-mvp-rxjava：只是学习一下rx在生产环境长什么样。

  • 不得不说，lamda表达式用到各种listener上很舒爽
  • 不得不说，Java8实在是应该赶紧用上
  • rx看得到的好处，就是把每一步遍历（flatMap）、合并（toList）、finally（doOnTerminate）等行为省略，改用对应的rx函数来做。如果熟悉，会非常易读、易维护
  • CompositeSubscription用来统一管理一个类中的所有订阅

• 自己的想法：

  • 抽象来说，一个App大概可以分为几个层面，依次向上依赖：
    
    • BizModel：业务模型，最核心的数据模型，大概相当于数据库的表。提供一个Bean
    • ModelStore：数据存取，核心数据存取逻辑，提供DAO
    • BizLogic：业务逻辑，将一段业务封装成一个小服务，供外部使用
    • ViewLogic：显示逻辑，将用户操作与业务逻辑粘合起来，提供ViewModel和View事件处理能力
    • ViewModel：显示模型，仅为显示提供完整的内容，View层仅使用和修改该Model
    • View：显示内容，真正的处理显示和用户事件
  • 各个MVC框架变种都是用不同的方式合并上述几个层面，或者是做各层面间交互的解耦

附依据该想法的简单demo