一篇文章了解架构模式:MVC/MVP/MVVM

架构模式的文章很多,好理解的没有几个。大部分文章出现的主要问题有:

  • 没有设定好作用域:前端MVC是改造过的MVC,和后台MVC有明显的区别,不能一概而论
  • 没有实际的例子:实际的例子对应日常的工作,没有就很难产生共鸣,从而造成看一次忘一次的困扰。
  • 没有明确的目的:理解架构模式的真正意义是什么?虚拟DOM和组件化在MV*中的位置?

题目开的太大,一定有很多疏忽错误的地方,也恳请大家指出。

1. MV*

1.1 后端MVC与前端MVC

从实现上来说,主要可以分为后端MVC和前端MVC两种。这两种MVC的不同点如下:
作者来源我暂时找不到了,找到了后补上

可以看到,前端的MVC其实是为了解决前端复杂JS模块化的问题,从后端MVC的V分出来的MVC,与后端MVC并没有直接的关系。前端的MVC中,M占的比例很低,只指代数据。而后端V的比例很低,只有模版的部分。

1.2 MVC/MVP/MVVM

图片描述

可以清晰的看出,这三个架构的区别在“M与V联系”的部分。下面我们针对这一部分做一个对比:

  • Controller: 负责监听View的用户事件,得到数据后Controller做一些处理,然后渲染View。
当然,在一些后端MVC架构里,Model也可以直接渲染View模版,但这只是不同变种的实现,这里不多做讨论。

但是随时逻辑的复杂,这样的处理遇到了很难调试的问题。由于View一定要运行在UI环境下,而且Model或者Controller和View强耦合,没有办法单独验证应用逻辑的正确性。当出了问题之后,因为各个模块是耦合在一起的,也不能快速判断究竟是哪个模块出现的问题。因此,MVP模式出现了。

  • Presenter: 比起Controller,Presenter会调用View层提供的接口去渲染Model。这样做有几点好处:

    • 面向接口编程
    • 更好的解耦
    • 方便做单元测试

现在P和V解耦了,P可以自己做单元测试了。软件结构划分的更加清楚,逻辑清晰并方便调试。但是这一切都来自于一个前提:View层要提供接口。当一个UI复杂起来的时候,View层需要提供的接口是很多的,这本身也是一种开发调试的成本。所以,MVVM应运而生。

  • ViewModel: 比起MVP中View需要自己提供API,MVVM在VM中构建一组状态数据(state data),作为View状态的抽象。然后通过双向数据绑定(data binding)使VM中的状态数据(state data)与View中的显示状态(screen state)保持一致。这样,VM中的展示逻辑只需要修改对应的状态数据,就可以控制View的状态,从而避免在View上开发大量的接口。

VM有没有什么缺点?有的,当UI比较简单的时候,使用VM就会使业务逻辑变得复杂,有过分设计的嫌疑。所以VM只适合复杂UI交互的项目。

2. 举个栗子

栗子🌰:现在用户下拉刷新一个页面,页面上出现10条新的新闻,新闻总数从10条变成20条。那么MVC、MVP、MVVM的处理依次是:

1. View获取下拉事件,通知Controller
2. Controller向后台Model发起请求,请求内容为下拉刷新
3. Model获得10条新闻数据,传递给Controller
4. Controller拿到10条新闻数据,可能做一些数据处理,然后拿处理好的数据渲染View
    MVC: 拿到UI节点,渲染10条新闻
    MVP: 通过View提供的接口渲染10条新闻
    MVVM: 无需操作,只要VM的数据变化,通过数据双向绑定,View直接变化

3. 了解架构的意义

最大的意义是站在创造者的角度上去思考问题,他们为什么要这么设计,这样做又有什么样的好处。当然,也有助于我们理解其他相关的知识。等到未来的某一天,当我们遇到更复杂的情况,用今天的MVVM也不能解决的时候,就可以顺着这样的思考脉络,重新进行架构设计,散发出自己的光。

备注:虚拟DOM与组件化
不管是虚拟DOM也好,还是组件化也罢,都是一种开发策略,而不是架构模式上考虑的问题。换句话说,它们与MV*是两个维度上的事情。所以把虚拟DOM和组件化扯入到MVC,MVP,MVVM的差异中并没有意义。

参考文献

  1. 浅析 MVC, MVP 与 MVVM之间的异同
  2. 前后端MVC的思考
阅读 6.4k

推荐阅读
汤姆C
用户专栏

tomczhang的专栏,我会在这个专栏中撰写我的思考,工作中遇到的问题和苦恼,每周一篇

311 人关注
43 篇文章
专栏主页