MVC、MVP、MVVM的成本角度结合业务，如何考虑选型？一文了解方方面面

大家都知道，使用架构的目的是使程序模块化，做到模块内部的高聚合和模块之间的低耦合，使得程序在开发的过程中，开发人员只需要专注于一点，提高程序开发的效率。那么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。

三者关系

1. 各部分之间的通信，都是双向的。
2. View 与 Model 不发生联系，都通过 Presenter 传递。
3. 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可能更适合，因为它们有助于保持代码的可维护性和可扩展性。

总结

看到这里你心中想必肯定有答案了吧，选择架构模式应该是一个全面的决策，需要考虑成本、可维护性、测试性、团队技能以及特定业务需求。可能需要在项目的不同部分使用不同的架构模式，以便根据情况进行最佳优化。

架构和模式并不是说让你的代码量更少了，往往可能还会增大，但是它帮你在逻辑上更简单的了，很好的定义了单一原则，提供了更好的扩展性，方便定位问题以及后续需求变更时不至于满篇的去改一大堆东西。