[架构]复杂App MVC重构小结

在公司做MVP重构，公司蛮大的，App也蛮复杂（显示逻辑上，业务转移上基本是用户操作驱动，而非业务逻辑驱动），所以是个大MVP，三端都非常臃肿。自然会用拆分来解决问题，同时参照了谷歌官方的架构模型。

Model

Model是数据层，该层是面向业务数据进行拆分的。安照SOLID思路，将Model拆成两层：

• 业务Model，这些Model承载着部分数据，以及面向这些数据的原子逻辑。但是，当涉及到持久化（服务端通信）时，需要通过Repo（见后）
• ModelGroup，简单的将子Model按类型进行组合，可以看做是对于组合哪些业务Model和如何持久化（针对Gson）的一个说明。其中的存储是Class->Object的Map，对外暴露一个通过Class获取Object的接口。从Repo层拿到的数据都是ModelGroup

View

此处主要是Passive View（xml），思想仍然是拆分，但要保证重用和对Presenter绑定的稳定：

• 子View，由定制化View、layout构成，是比复杂Fragment更小的View部分，绑定到单一的Presenter上（该Presenter可以按需拆分成更小的部分）
• ViewGroup，由粘合（摆放子layout的ViewGroup）和include子layout实现。会成为Activity/Fragment的根View，承载了一个完整的页面

Presenter

Presenter尽量简化对外接口（只有生命周期，分离关注），用以粘合View-Model。该层是面向显示和业务进行拆分的。后续可以比较简单的衍化到MVVM中的ViewModel。

• 子Presenter，负责一个子layout和一个业务Model的粘合，如果该layout需要多个Model，则由多个子Presenter实现（演化成VM时，需要用clean arch或者其他方案合并Presenter）。
• PresenterGroup，可以是Presenter或者Activity/Fragment，PresenterGroup持有的是ModelGroup和ViewGroup，主要负责将ModelGroup Convert到Model，并将子Presenter绑定到对应的View上

Converter

新增层，用以将ModelGroup在绑定时转换到子Presenter所需的Model。可以极大的提高子Presenter的重用能力，而且可以保证子Presenter的SOLID。

Repo

新增层，隔离持久化/服务端逻辑，并且包装了Model层转换的工作。同时，作为传递数据的核心，方便实现全局对同一Model的KVO。

职能表

A依赖B：A知道B的存在，有B的reference、new了B的实例或调用B的自定义构造方法。
A使用B：A依赖B，且调用了B的方法或访问了B的field。

部分 职责 依赖 使用 备注 单测 Activity Fragment调度 Fragment Repo、Model 使用Model应该只存在于使用Model增减Fragment的情况下 否 Fragment Binding Converter、Model、View Presenter、Repo Presenter仅使用生命周期方法 否 Repo 存取传递Model Model Store 是 Store 以不同方式存取Model Model 是 Converter Model转换 Model 是 Model 面向数据的业务逻辑 Repo 是 View xml和定制widget MVVM会使用到Presenter/ViewModel 否 Presenter 绑定View和Model View、Model 仅当输出为ViewState时可测