Android几种项目架构的优缺点

转载请注明：原文地址：https://www.jianshu.com/p/1912473dff9a

Android几种项目架构的优缺点

MVC架构
MVC, 即Model-View-Controller, 基于页面逻辑的修改要多于业务逻辑, 分离两种逻辑减少类代码的修改.

Model: 即数据层, 负责处理业务逻辑, 监听网络与数据库接口.
View: 即界面(UI)层, 显示来源于Model的数据.
Contoller: 即逻辑层, 传递用户的交互和更新Model的数据.

优点
MVC模式, 分离类的UI与业务职责, 增加可测试性与可扩展性. Model不引用任何Android类, 允许单元测试(Unit Test). Controller含有View的引用, 不引用Android类, 允许单元测试. View满足单一职责原则(SRP), 传递事件至Controller, 展示Model数据, 不包含业务逻辑, 允许UI测试.

缺点
View既依赖于Controller又依赖于Model. 在修改UI逻辑时, 也需要修改Model, 降低架构的灵活性. View与Model的职责部分重叠, 过于耦合, 在处理UI逻辑时, 被动模式与主动模式都会产生若干问题.

在被动模式中, Controller通知Model更新数据, 并通知View显示. 对于UI逻辑, 如果View处理, 单元测试会遗漏逻辑; 如果Model处理, 则隐式地依赖于View, 导致模块增加耦合.

MVP架构
MVP架构包含三大模块, 即Model, View, Presenter.

Model: 即数据层, 负责处理业务逻辑, 监听网络与数据库接口.
View: 即界面(UI)层, 展示数据, 响应用户事件并通知Presenter.
Presenter: 即展示层, 接收Model的数据, 处理UI逻辑, 并管理View的状态, 根据View层事件提供展示数据.

优缺点
MVP架构更好地分离View与Model之间的职责, 解除UI逻辑之间的耦合.

对于小型项目而言, 与设计模式类似, 会导致过度设计, 增加代码量. 当处理复杂页面时, Presenter层会包含大量UI逻辑与业务逻辑, 非常冗余, 并违反单一职责原理.

MVP架构的核心在于Presenter层. Presenter打破Model与View之间的耦合, 创建展示数据的通道, 隔离业务逻辑, 支持单元测试. 还有另一个架构, MVP的进化版MVVM.

MVVM架构
MVVM包含三个模块, Model, View, ViewModel.

Model: 即DataModel, 抽象数据源, ViewModel从Model中读取或存储数据.
View: 当用户触发响应事件时, 通知ViewModel, 展示提供的数据.
ViewModel: 提供View显示的数据流.

优势
MVVM的优势是进一步解耦UI逻辑与业务逻辑. ​

View与ViewModel的耦合, 弱于View与Presenter的耦合.
View仅是ViewModel的消费者, 当修改UI时, 不修改ViewModel.
根据业务关注点, 创建多个高内聚的View与ViewModel, 允许多个页面共享与替换.
彻底分离UI逻辑, 使用DataBinding分离UI显示与UI逻辑.
View与ViewModel一对多, ViewModel与Model多对多.
ViewModel和Model与UI界面完全解耦, 进一步提高可测试性.
MVVM, 与MVP类似, 也是非常优秀的架构模式, 在开发中, 使用架构比无序开发, 可以极大地提高项目的稳定性与可测性.