为什么要用MVVM

MVVM的核心概念就是MV和VM的分离与耦合，也就是表现层与逻辑层的分工。
这实际上是专业化（专门化）与敏捷开发导致的框架思维。

在一开始，做软件几乎都是像你这样，一个人带一个项目，搞全栈，后端想到什么业务逻辑，直接就把前端对应的界面做了，非常的快捷方便。但是同时带来的问题就是软件不好看，界面样式非常的单一，要么花里胡哨，为了炫技而堆砌，要么一招鲜吃遍天，一种UI布局反复套用，让人看了疲惫。

因此，就需要引入专业化的思想——专业的人干专业的事儿。由专业的美工来设计软件界面，但是美工不懂编程，所以中间还得在插入一个前端，来负责实现美工的想法。由此，软件开始变得越来越美观，UI也可以迭代出很多套方案来。

而互联网的浪潮来了之后，人们对技术迭代的速度又提出了更高的要求，今天一个提案，明天就得上线，尤其是UI，需求变化极其多样，时效性又非常强，比如到了什么节日，所有控件都得加上什么装饰，统一改成节日风格的，或者某个伟人的祭日，要统一改成黑白的。也就是换肤那一套。

面对这种需求，你不可能再像传统的那种开发流程，各个职能单位逐个流转，美工给前端，前端给后端，后端说做不了再返给前端，前端发现根本上是美工设计的太复杂了，就要求美工再整改。美工改完了再给前端，前端给后端，这一套折腾下来，早就过了交付时间了。

再就是敏捷开发，核心的业务逻辑就是那么一套，但是给不同的客户定制，界面都会要求不一样，可能同一套业务流程，软件长得完全不同，但市场不会等你，人家就觉得，功能你们都具备了，为什么交付这么慢?所以以前的模块化开发，组态设计，现在流行的低代码平台，都是这么应运而生的。

而MVVM也是为了解决这个问题，他实际上就是从框架上给UI的专门化提供了便利。MVVM这个框架提供出来是什么?不是提供了若干个组件，让你省去很多开发时间。而是提供了一套规范，一个从前约定俗成的标准，现在给你纸面化了。只要后端按照这个标准去走，那么前端，甚至美工，可以独立去更新UI设计，而无须繁琐的交接流程，并且在定制化开发的时候，根本无需后端的核心算法工程师的参与，一个前端一个美工一个简单的后端配合，就足够完成敏捷开发了，实现快速交付。

说点儿实际的。假设你有一个窗口，里面有10个功能模块，这10个模块你打算怎么呈现?可以用tab选项卡吧，也可以用导航菜单，还可以全都平铺在主窗体上，还可以一部分平铺一部分折叠。
那现在有4个客户，要求UI都不一样，那你是不是要分别采用上面四种UI风格？那你难道还要单独开发四个软件吗？
用MVVM的话，你在主窗体里面只要写好功能模块的定义，数据字段，命令Command，那我管你窗口上实际是个按钮还是超链接？反正都是某个“可点击的东西”，作为后端，只要确保有个点击的入口即可，前端去构思用什么UI控件来接入，这就是前后端分离，UI分工专门化。这才是mvvm思想的核心和精髓。

而如果你的软件，就是一个人搞全栈，又没有UI定制化的需求，mvvm就确实是个累赘，反倒徒增代码量，拖累软件性能。
-- 转自知乎潘晨