大家都知道,使用架构的目的是使程序模块化,做到模块内部的高聚合和模块之间的低耦合,使得程序在开发的过程中,开发人员只需要专注于一点,提高程序开发的效率。那么MVC、MVP、MVVM,该怎么选?在什么最省去开发时间和业务成本?
本篇来彻底理解MVC、MVP、MVVM这三个架构模式。首先我们来了解这三个架构模式原理简单解析
MVC、MVP、MVVM简单解析
MVC(Model-View-Controller)
Model:数据模型,用来存储数据 View:视图界面,用来展示UI界面和响应用户交互 Controller:控制器(大管家角色),监听模型数据的改变和控制视图行为、处理用户交互。
MVC是比较直观的架构模式,用户操作->View(负责接收用户的输入操作)->Controller(业务逻辑处理)->Model(数据持久化)->View(将结果反馈给View)
三者关系
在MVC中,View是可以直接访问Model,那么View里会包含Model的信息,不可避免的也包含一些业务逻辑。在MVC模型里,更关注的Model改变,而同时有多个对Model的不同显示,即View。所以,在MVC模型里,Model不依赖于View,但View是依赖于Model。而对Android来说,activity基本承担来view层和controller层两种角色,并且和model层耦合严重,在逻辑复杂的界面维护起来很麻烦。那么这时候MVP出来,切断View和Model之间的关系。
MVP(Model-View-Presenter)
MVP 模式将 Controller 改名为 Presenter,同时改变了通信方向。
Model:数据模型,用来存储数据 View:视图界面,用来展示UI界面和响应用户交互 Presenter:展示器,Presenter是从Model中获取数据并提供给View层,简单的就是当View需要去更新数据时,首先找Presenter,Presenter然后去向Model请求数据,从Model获取数据之后通知Presenter,Presenter再通知View去更新数据。简而言之:返回什么数据给View。
三者关系
- 各部分之间的通信,都是双向的。
- View 与 Model 不发生联系,都通过 Presenter 传递。
- View 非常薄,不部署任何业务逻辑,称为"被动视图"(Passive View),即没有任何主动性,而 Presenter非常厚,所有逻辑都部署在那里。
MVVM(Model-View-ViewModel)
m:model 数据层 v:view 视图层 vm: 数据双向绑定
MVVM(Model-View-ViewModel)是一种软件架构设计模式,它是MVC的增强版,实质上和MVC没有本质区别,MVVM是以“数据模型数据双向绑定”的思想作为核心,因此在View和Model之间没有联系,而是通过ViewModel进行交互,而且Model和ViewModel之间的交互是双向的,因此视图数据的变化会同时 修改数据源,而且数据源数据的变化也会立即反应到View上。 三者关系
这里是引用资料摘要:《Android核心开发手册》点击可查看详细进阶板块。
开发选型
开发成本:
- MVC通常是最简单的,因为它没有明确的分层。但随着项目复杂度的增加,可能会导致代码耦合问题,增加维护成本。
- MVP相对来说需要更多的代码,因为它需要为每个视图编写一个Presenter,但它有助于更好地分离关注点。
- MVVM通常需要更多的初始工作,因为它们需要创建ViewModel或Intent,并且通常使用数据绑定库,这可能需要学习和实施额外的工具和框架。
测试成本:
- MVC的测试通常较为困难,因为它的代码耦合度高。
- MVP使单元测试更容易,因为逻辑分离得更清晰。
- MVVM通常也易于测试,因为它们鼓励将业务逻辑与UI分开。
维护成本:
随着时间的推移,MVC可能会导致代码膨胀和维护困难,因为它的耦合度高。 MVP和MVVM提供了更好的可维护性,因为它们分离了关注点。
学习成本:
- MVC相对容易学习,因为它没有太多的抽象概念。
- MVP需要理解Presenter的角色,可能需要一些学习曲线。
- MVVM需要理解ViewModel或Intent以及数据绑定的概念,可能需要更多的时间来学习和实践。
项目复杂度:
- 对于小型项目,MVC可能足够,因为它更简单。
- 对于中等到大型项目,MVP、MVVM可能更适合,因为它们有助于保持代码的可维护性和可扩展性。
总结
看到这里你心中想必肯定有答案了吧,选择架构模式应该是一个全面的决策,需要考虑成本、可维护性、测试性、团队技能以及特定业务需求。可能需要在项目的不同部分使用不同的架构模式,以便根据情况进行最佳优化。
架构和模式并不是说让你的代码量更少了,往往可能还会增大,但是它帮你在逻辑上更简单的了,很好的定义了单一原则,提供了更好的扩展性,方便定位问题以及后续需求变更时不至于满篇的去改一大堆东西。