MVVM、MVP、MVC、AndroidFlux 这几种主流的架构设计介绍

MVC

MVC 简单来说就是将整个应用分为 Model、View 和 Controller 三个部分

1. 视图层（View）：对应于xml布局文件和java代码动态view部分

2. 控制层（Controller）：主要负责业务逻辑，在android中由Activity承担，同时因为XML视图功能太弱，所以Activity既要负责视图的显示又要加入控制逻辑，承担的功能过多。

3. 模型层（Model）：主要负责网络请求，数据库处理，I/O的操作，即页面的数据来源

• 

案例分析

Android中的ListView就用到了MVC设计模式

• M：数据的集合，List
• V：ListView
• C：Adapter，控制数据如何显示在ListView上

而Activity控制层和视图层都有

MVC架构在android平台上的主要存在以下问题：

1. Activity同时负责View与Controller层的工作，违背了单一职责原则

2. Model层与View层存在耦合，存在互相依赖，违背了最小知识原则

MVP

MVP架构主要分为以下几个部分：

1. View层：对应于Activity与XML,只负责显示UI,只与Presenter层交互，与Model层没有耦合

2. Presenter层：主要负责处理业务逻辑，通过接口回调View层

3. Model层：主要负责网络请求，数据库处理等操作，这个没有什么变化

我们可以看到，MVP解决了MVC的两个问题，即Activity承担了两层职责与View层与Model层耦合的问题。但MVP架构同样有自己的问题：

1. Presenter层通过接口与View通信，实际上持有了View的引用

2. 但是随着业务逻辑的增加，一个页面可能会非常复杂，这样就会造成View的接口会很庞大。

MVVM

MVVM（Model-View-ViewModel）是一种软件架构设计模式，用于将业务逻辑、界面表示和用户交互分离。MVVM 架构包含以下三个主要组件：

• Model：负责处理数据和业务逻辑。

• View：负责显示 UI，并将用户操作传递给 ViewModel。

• ViewModel：负责处理 View 的输入，并更新 Model，同时通知 View 更新。

MVVM 架构模式是微软在 2005 年诞生的，第一次进入 Android 人员视野是从 Google 2015 推出 DataBinding 组建开始，后续 Google 不断的推出了 ViewModels、LiveData、Android Loader、Lifecycles 等适用于 MVVM 架构的组件，由此可见 Google 已经“钦定” MVVM 是 Android 开发未来的第一架构了。

MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。唯一的区别是，它采用双向数据绑定（data-binding）：View的变动，自动反映在 ViewModel，反之亦然。

MVVM 架构

可以看出MVVM与MVP的主要区别在于,你不用去主动去刷新UI了，只要Model数据变了，会自动反映到UI上。换句话说，MVVM更像是自动化的MVP。

 以上三种架构小结：

• MVC架构的主要问题在于Activity承担了View与Controller两层的职责，同时View层与Model层存在耦合

• MVP引入Presenter层解决了MVC架构的两个问题，View只能与Presenter层交互，业务逻辑放在Presenter层

• MVP的问题在于随着业务逻辑的增加，View的接口会很庞大，MVVM架构通过双向数据绑定可以解决这个问题

• MVVM与MVP的主要区别在于，你不用去主动去刷新UI了，只要Model数据变了，会自动反映到UI上。换句话说，MVVM更像是自动化的MVP。

• MVVM的双向数据绑定主要通过DataBinding实现，但有很多人(比如我)不喜欢用DataBinding，而是View通过LiveData等观察ViewModle的数据变化并自我更新,这其实是单一数据源而不是双向数据绑定

MVI架构参考：MVVM 进阶版：MVI 架构了解一下

AndroidFlux

AndroidFlux 是 Facebook 的 Flux 架构的 Android 实现。 Flux 是 Facebook 在14年提出的一种 Web 前端架构，主要用来处理复杂的 UI 逻辑的一致性问题（当时是为了解决 Web 页面的消息通知问题）。经过实践之后发现，这种架构可以很好的应用于 Android 平台，相对于其他的 MVC/MVP/MVVM 等模式，拥有良好的文档和更具体的设计，比较适合于快速开发实现。

Flux 模式最大的特点是单向的数据流，它的 UI 状态更新模式继承了 MVC 模式的设计思想。 Flux 并不是具体的框架，而是一套处理 UI 问题的模式， AndroidFlux 同样不是具体的框架，你不需要导入或者集成任何新的代码就可以使用，而你需要做的事情是了解这套思想、遵循这种开发模式。

AndroidFlux 架构

上述内容取自 AndroidFlux QUICK START。

AndroidFlux 的结构设计很容易让我们想到函数式响应编程（functional-reactive-programming），而且 AndroidFlux 一直在强调它自己本身并非某种具体的框架而是一种 UI 或者说数据流的走向，这个很像我们熟知的 RxJava 设计思路，所有事件、UI 都可以当作为一个数据流并加以处理。

AndroidFlux 的数据流动

只有一个Dispatcher

在 AndroidFlux 应用中 Dispatcher 是中心枢纽，管理所有的数据流。它实际上管理的是 Store 注册的一系列回调接口，本身没有其他逻辑 —— 它仅仅是用来把 Action 发送到各个 Store 的一套简单的机制。每个 Store 都会把自己注册到这里，并提供自己的回调方法。当 ActionCreato 给 Dispatcher 传递一个 Action 的时候，应用中所有的 Store 都会通过回调接口收到通知。

随着 App 的增长，Dispatcher 会变得更加重要，它可以通过调整回调方法的触发次序来管理 Store 之间的依赖关系。Store 可以声明等待其他 Store 更新完毕再更新自己。

Stores

Store 包含应用的状态（State）和逻辑（Logic）。它扮演的角色和 MVC 模式中的 Model 类似，但是它会管理多个对象的状态 —— 它不是像 ORM-Model 一样的单独的数据集。Store 负责管理App中一片区域（Domain）的状态，而不是简单的ORM数据集。

由于 AndroidFlux 是一串的语法、结构规范，他并没有什么组件来协助我们开发，所以使用 AndroidFlux 的难度较高，暂时不考虑在中、小型团队中的应用，仅仅作为一个知识拓展。

总结

在架构模式的选用时，我们往往没有太多的发言权，主要因为平台本身往往对应用层有着自己的设计，我们在开发客户端或者前端应用时，只需要遵循平台固有的设计就可以完成应用的开发，不过，在有些时候，由于工程变得庞大、业务逻辑变得异常复杂，我们也可以考虑在原有的架构之上实现一个新的架构以满足工程上的需要。

最终由于项目上人手不足，我们的项目很遗憾只能选择 MVP 进行重构，但是其他的架构也给我们提供了不错的思路如 MVVM 架构中 Google 官方提供的绑定组件，AndroidFlux 将 UI 作为响应式编程的一部分，这些好的地方都值得我们去反复揣摩深入学习，后续的文章将会陆续的和大家一起讨论一下我们在项目重构中经历过的一些问题，以及我们是如何设计出一个相对简单易用的通用开发架构。

参考链接:https://mp.weixin.qq.com/s/m65COgPmsNYN1GcsV8g9hA

MVC，MVP，MVVM设计模式的比较_JackChan-CSDN博客

使用 Flutter 实现 MVVM 架构