背景
我就想看看MVP怎么搞…
分层架构
代码行数：~290
文件目录结构：
NotesFragment.java
优点：
- 业务分层，把fragment的初始化分成
initView(), initData(), initListener() - 功能分区，按
View, Data, Listener,在fragment文件内部分区，用注释隔开，简单易懂缺点：
- fragment持有内部类 - 数据的刷新需要context, 应该做到数据与状态无关，易于复用
- fragment管的东西太多
基础MVP架构
代码行数：~160
目录结构：
notes ├── model │ ├── NotesDataManagerAction.java │ └── NotesDataManager.java ├── presenter │ ├── NotesPresenterAction.java │ └── NotesPresenter.java └── view ├── CardStackViewAdapter.java ├── ColorItemViewHolder.java ├── NotesFragmentAction.java └── NotesFragment.java
优点：
- 数据（model）和UI（view）解耦，双方都只暴露接口给presenter，由presenter决定数据和UI的互动
- NotesFragment只作为view层，下放业务处理能力给presenter，使代码量大量减少（实际是转移给presenter，没有减少）
- NotesFragment不再持有内部类，加载速度增加
- 在数据层去掉context，使data与view相互独立
缺点：
- 没有绑定view，presenter可能在fragment销毁后仍有其引用，导致内存泄漏
- NotesFragment里除了需要显示的view的初始化就都是接口的具体实现，对新手不友好
高级MVP架构
代码行数：~160
目录结构：
notes/ ├── model │ └── NotesDataManager.java ├── presenter │ └── NotesPresenter.java └── view ├── CardStackViewAdapter.java ├── ColorItemViewHolder.java ├── NotesFragmentAction.java └── NotesFragment.java
优点：
- 高度抽象，减少代码冗余（比如绑定view）
- 使用代理模式将绑定和解绑view的操作抽离出来
- 使用工厂模式和注解在上层统一创建Presenter
- 将Presenter的创建过程放入到获取Presenter的方法中，如果存在返回，不存在创建，保证Presenter不会为空，保证在使用的时候再创建，节省内存资源
- 删除不必要的接口文件，用分区的方法突出类内可调用的业务处理函数 - 总的来说就是耐操
缺点：
- 新手不友好，依赖注入设计模式等操作有一定的复杂度
- MVP固有缺点：每条逻辑都要有完全不同的presenter来管理
- 添加多个presenter麻烦