职责划分

前面已经提到, MVP没有固定的形式, 但是代码是死的, 人是活的, 开发团队制定一个标准, 然后大家遵守执行, 在一定程度上能解决这个问题. 因此, 在此我会尽量通过各种使用场景将M, V, P各自的职责具象化.

注意: 其他所有特殊的具体情况均默认包含了基本职责

1. 基本

• View

  • 显示/隐藏加载框

  • UI与数据的绑定

  • 显示错误消息

  • 页面跳转

  • 转发请求至Presenter

  • 发送/监听RxBus事件

• Presenter

  • 转发请求至Model

  • 检查用户输入是否合法

  • 控制View显示/因此加载框

  • 解析请求结果

  • 控制View显示错误消息

  • 控制View进行界面跳转

  • 控制登录状态

  • 从Model获取本地数据

  • 发送/监听RxBus事件

  • 尽量不要持有Context等与Framework相关的对象.

• Model

  • 发送网络请求

  • File/SP/DB数据存取

2. 上传图片

• View

  • 压缩图片

  • 转发上传请求至Presenter

• Presenter

  • 转发上传请求至Model

• Model

  • 上传图片

3. 分页

• View

  • 显示/隐藏正在加载

  • 显示所有页数加载完成

• Presenter

  • 控制页数的增长, 控制页数的置零

  • 控制何时能请求下一页, 何时不能请求下一页.

  • 控制View显示所有页数加载完成

  • 控制View显示/隐藏正在加载

to be continued...

MVP不是银弹, Clean也不是银弹, 引入了MVP, Clean也不能立即就提高代码质量, 减少bug. 重点不是学习架构, 而是学习这种思维: 如何把缠在一起的代码拆分, 如何把拆开的代码再组合. 如何在解决问题的时候把问题合理的拆分, 又如何将拆分的零件合理的组装成解决问题的工具. 只有真正将这种思维方式融入到自己代码的每一处, 才能从根本上解决质量的问题.