前言

• MVC（Model-View-Controller）
• MVP（Model-View-Presenter）
• MVVM（Model-View-ViewModel）

M、V 是这三种架构模式中的共同含有的部分，M 是 Model 的缩写，代表“数据模型”；V 是 View 的缩写，代表“视图”。
这三种架构设计中，都对 M 和 V 进行了分离，Model 掌握数据源，View 负责视图展示。而剩下的部分（MVC 中的 C、MVP 中的 P、MVVM 中的 VM），就是不同架构中对 M 与 V 之间“交互”的特色处理。

没有接触过业务的话，大量的谈论这些UI设计模式没什么意义。

当我们做了大量的业务，就会接触到大量的需求和大量的数据，这些数据需要显示在视图层上。如果直接写在一起，当数据层变化的时候，就需要改动到整个业务，这对开发和测试来说都是很不友好的，所以以上这些设计应运而生，以上几个模式的目的都是为了model（数据层）和view（视图层）的解耦。

Model-View-Controller

model负责数据抽象，view负责图形界面（web应用中基本上就是组合生成html代码），controller负责接受、处理和响应客户端的请求。MVC 的不足是 Model和 Controler 在处理完成后，会有机制通知 View，一般采用“观察监听”设计模式。

MVC的一般流程是这样的：View【界面】比如按钮触发事件--》Controller【业务】处理了业务（向服务端发送请求），然后（服务端回包）触发了数据更新--》更新了Model的数据--》Model【数据】带着数据回到了View--》View更新数据

举个例子：

button点击事件的触发：View→Controller
获取用户信息事件的触发：Controller→Model
绑定用户信息到View：Controller→View

Model-View-Presenter和一些衍生

mvp是在mvc的基础上，切断了View和Model的联系，让View只和Presenter（原Controller）交互，减少在需求变化中需要维护的对象的数量。

Model-View-ViewModel

ViewModel大致上就是MVP的Presenter和MVC的Controller了，而View和ViewModel间没有了MVP的界面接口，而是直接交互，用数据“绑定”的形式让数据更新的事件不需要开发人员手动去编写特殊用例，而是自动地双向同步。就是在Model的set接口对viewModel进行数据更新

看起来MVVM很好的解决了MVC和MVP的不足，但是由于数据和视图的双向绑定，导致出现问题时不太好定位来源，有可能数据问题导致，也有可能业务逻辑中对视图属性的修改导致。如果项目中打算用MVVM的话可以考虑使用官方的架构组件ViewModel、LiveData、DataBinding去实现MVVM

参考

从Web开发的角度聊聊MVC、MVP和MVVM

MVC、MVP、MVVM，我到底该怎么选？