一文了解MVC、MVP、MVVM、MVI架构

创作时间:

作者:

@小白创作中心

一文了解MVC、MVP、MVVM、MVI架构

引用

来源

https://juejin.cn/post/7478179664554573874

在Android开发中，选择合适的架构模式对于提高开发效率和代码质量至关重要。本文将深入解析MVC、MVP、MVVM和MVI这四种主流架构模式，帮助开发者理解它们之间的区别和适用场景。

MVC

MVC（Model-View-Controller）架构如下图所示：

从图中可以看出，MVC架构主要分为以下几部分：

视图层（View）：对应于XML布局文件和Java代码动态View部分
控制层（Controller）：主要负责业务逻辑，在Android中由Activity承担，同时因为XML视图功能太弱，所以Activity既要负责视图的显示又要加入控制逻辑，承担的功能过多。
模型层（Model）：主要负责网络请求，数据库处理，I/O的操作，即页面的数据来源

可以看到MVC的完整数据流向是：View → Controller → Model → View。这样的数据流向有个问题，就是由于Model直接操作View，导致Model和View耦合。

而在Android中，由于XML布局的功能性太弱，Activity实际上负责了View层与Controller层两者的工作。所以在Android的MVC中，Controller和View层其实是一起的。如下图所示：

总结一下，MVC在Android上的问题主要有：

Activity同时负责View与Controller层的工作，违背了单一职责原则
Model层与View层存在耦合，存在互相依赖，违背了最小知识原则

MVP

MVP（Model-View-Presenter）的架构如下图所示：

从图中可以看到MVP架构主要分为如下部分：

View层：对应于Activity与XML，只负责显示UI，只与Presenter层交互，与Model层没有耦合
Presenter层：主要负责处理业务逻辑，通过接口操作View层
Model层：主要负责网络请求，数据库处理等操作，这个和MVC架构一样

可以看到在MVP架构中，数据的流向是View → Presenter → Model → Presenter → View。它与MVC架构最大的不同就是，View和Model不相互耦合，都通过Presenter做中转。同时MVP架构让View层，即Activity只展示UI，从而解决了Activity同时负责View与Controller层的工作的问题。

但是MVP架构也有不足，它的缺点如下：

Presenter层通过接口与View通信，实际上持有了View的引用
随着业务逻辑的增加，一个页面可能会非常复杂，这样就会造成View的接口会很庞大。

MVVM

MVVM（Model-View-ViewModel）架构如下图所示：

从图中可以看到MVVM架构主要分为如下部分：

View视图：负责界面的展示。
ViewModel控制器：负责逻辑控制。
Model模型：负责数据的加载和存储。

可以看到ViewModel层其实和MVP层的Presenter功能是一样。MVVM和MVP的主要区别是，MVVM增加了双向数据绑定的功能，即View和ViewModel的变动都会自动反应到对方。MVVM的数据流向为View ↔ ViewModel → Model → ViewModel ↔ View

在Android中，双向绑定一般由DataBinding实现。但是由于DataBinding存在的调试困难、复杂场景需要高度定制等问题，大部分开发者都会使用LiveData、Flow来观察数据变化，从而实现双向数据绑定。

MVVM的缺点如下：