MVC MVP MVVP Android端构建个人总结

黑发不知勤学早，白首方悔读书迟。

 

MVC

MVC (Model-View-Controller, 模型-视图-控制器) Trygve Reenskaug在1978年提出(维基百科)：

• 模型（Model） - 程序员编写程序应有的功能（实现算法等等）、数据库专家进行数据管理和数据库设计(可以实现具体的功能)。
• 视图（View） - 界面设计人员进行图形界面设计。
• 控制器（Controller）- 负责转发请求，对请求进行处理。

君生我未生，永不过时的经典软件架构模式。

对应于Android开发：

• 模型（Model） - 数据结构演化成bean，对于Android而言Model层主要是数据仓库(repository)，比如：本地数据库仓库(LocalDBRepository)、远程数据仓库(ServiceRepository)、SharedPreferences等等。
• 视图（View） - xml文件 + Activity、Fragment等等。
• 控制器（Controller）- Activity、Fragment等等。

SDK虽然已经分离出了MVC，但是因为xml文件的限制，Activity等不得不承担部分View的职责。也就导致了Activity代码膨胀，多重职能交错维护成本指数增加。即使抽离出ViewHolder，又可能涉及内存泄露等问题，未从根本上解决Activity的根本问题。

同时，MVC不限制三者通讯，互相持有、调用等灵活使用，又因为OOM的情况，这种灵活在Android端不是一种非常正面的优势。软件架构本身就是为了高屋建瓴的规避bug，提升代码可读性，提高可维护性，简化团队协同。毕竟大佬用txt都能写出优雅的代码。

对于Android开发而言MVC的痛点：

1. Activity职能分离不彻底。既是View又是Controller。
2. Activity代码膨胀，业务一复杂，太考验开发者拆分能力。

 

MVP

Model-View-Presenter (MVP) 是用户界面设计模式的一种，被广泛用于便捷自动化单元测试和在呈现逻辑中改良分离关注点（separation of concerns）(维基百科)。

• Model 定义用户界面所需要被显示的资料模型，一个模型包含着相关的业务逻辑。
• View 视图为呈现用户界面的终端，用以表现来自 Model 的资料，和用户命令路由再经过 Presenter 对事件处理后的资料。
• Presenter 包含着组件的事件处理，负责检索 Model 获取资料，和将获取的资料经过格式转换与 View 进行沟通。

MVC进化演变，天演论无处不在。

对应于Android开发：

• Model 数据结构演化成bean，对于Android而言Model层主要是数据仓库(repository)，比如：本地数据库仓库(LocalDBRepository)、远程数据仓库(ServiceRepository)、SharedPreferences等等。
• View xml文件 + Activity、Fragment等等，将所有的页面操作暴露成方法供Presenter调用。
• Presenter 同时持有Model+View，处理所有判断逻辑，Model和View不再能够直接交流，所有的沟通都需要通过Presenter"转手"。由于Contract的接口，因此Presenter里面有很多简单“转手”的方法。例如：更新某个TextView的值。同时View和Presenter发生任何业务改动，View、Presenter和Contract都需要同步更改。

解决了MVC职能分离不彻底的问题，但是代码膨胀的问题转移到了Presenter中，因为“转手”方法的存在，雪泥鸿爪，代码膨胀且更甚之。也带来了优点便捷自动化单元测试。

对于Android开发而言MVP的痛点：

1.Presenter代码膨胀，业务一复杂，同样考验开发者拆分能力。
2.业务改动需要改动的地方过多，简单代码冗余。

 

MVVM

Model-View-ViewModel（MVVM）微软2005年提出，旨在利用数据绑定，通过从视图层中几乎删除(隐藏)所有GUI代码，更好地促进视图层开发与模式其余部分的分离(维基百科整理)

• Model 模型是指代表真实状态内容的领域模型（面向对象），或指代表内容的数据访问层（以数据为中心）。
• View 就像在MVC和MVP模式中一样，视图是用户在屏幕上看到的结构、布局和外观（UI）。
• ViewModel 视图模型是暴露公共属性和命令的视图的抽象。MVVM没有MVC模式的控制器，也没有MVP模式的presenter，有的是一个绑定器。在视图模型中，绑定器在视图和数据绑定器之间进行通信
• Binding  声明性数据和命令绑定隐含在MVVM模式中。在Microsoft解决方案堆中，绑定器是一种名为XAML的标记语言。绑定器使开发人员免于被迫编写样板式逻辑来同步视图模型和视图。在微软的堆之外实现时，声明性数据绑定技术的出现是实现该模式的一个关键因素。

MVC另一个进化分支，百花齐放。

对应于Android开发：

• Model 数据结构演化成bean，对于Android而言Model层主要是数据仓库(repository)，比如：本地数据库仓库(LocalDBRepository)、远程数据仓库(ServiceRepository)、SharedPreferences等等。
• View xml文件 + Activity、Fragment等等，在xml进行数据绑定，Activity前所未有的轻薄。
• ViewModel 不再持有View，通过数据改变驱动View更新，更纯粹的关注逻辑问题。
• Binding  官方提供DataBinding+LiveData，帮助开发者处理了“转手方法”，LiveData解决CallBack问题。

MVP“转手”方法的问题解决了，也带来了新的问题。
1. 必须依赖的lib增加，必须依赖于一套Binding框架，Android几乎都是使用官方的。勉强能接受，编译时间长一丢丢。
2. 与MVP相比，解决了冗余的“转手”方法。
3. 逻辑膨胀带来的代码膨胀，同样考验开发者拆分能力
4. 自动生成的代码代码调试不便

 

个人总结

MVP和MVVM俨然更适合Android软件开发架构。又各有千秋，选择对的，事半功倍。

（MVP有成熟的已上线项目支持，MVVM仅开发了一个四五个页面的简单demo，贻笑大方之处望不吝赐教）

1. 业务膨胀导致代码膨胀，目前只能通过开发者拆分，架构似乎无法避免
2. 上手难度，如果不考虑Dagger的MVP上手难度是低于MVVM的。
3. 轻重级，MVVM偷懒更多，编译的时间自然更长，依赖更多。
4. MVP的“转手”方法确实写着无趣。
5. MVVM的RecyclerView写着真的爽，MVP的Adapter则不然。
6. 通过DataBinding的扩展，能够解决很多重复的UI相关代码，简直不能太香。

于2021.1.15  之后有了新的理解或再修正。

2021.3.19补：
官方jetpack组件库的加持之下，混沌初开的乱象已经不复存在，现在移动端的原生开发跟前端的发展轨迹如出一辙：混乱走向标准化、流程化。对于公司而言人员流动带来的代码维护问题减少，对个人接手别人的代码更简单，组件化加持下业务与业务模块之间不在天堑鸿沟，同时也带来了新的挑战与学习。

更贴合交互段的编码方式，数据驱动替代以前的事件驱动成了必然。MVVM yyds!