MVC
MVC思想是一种设计模式。最常见的软件架构之一。
其中M代表Model，指的是数据层，负责数据的管理，例如数据的请求更新，存储。
V代表View，指的是视图层，负责用户界面的呈现。
C，Controller控制器，是M层与V层之间的协调器。例如当用户在页面上鼠标点击或者键盘操作某个事件的时候，如果使数据发生了变化，那么C层会把这个变化更新到model层，同时会监听model层的变化及时更新到V层。
所有通信都是单向的。
image.png
- View 传送指令到 Controller
- Controller 完成业务逻辑后，要求 Model 改变状态
- Model 将新的数据发送到 View，用户得到反馈
MVC 优缺点
优点是让代码的可读性更高，方便之后的维护和扩展。
缺点是该框架虽然也是把代码逻辑和UI层分离，但是View层能做的事情还是很少的，很多对于页面的呈现还是交由C实现，这样会导致项目中C的代码臃肿，如果项目小，代码臃肿点还是能接受的，但是随着项目的不断迭代，代码量的增加，你就会没办法忍受该框架开发的项目，这时MVP框架就应运而生。
MVP
MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。
image.png
- 各部分之间的通信，都是双向的。
- View 与 Model 不发生联系，都通过 Presenter 传递。
- View 非常薄，不部署任何业务逻辑，称为"被动视图"（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
MVVM
为了解析数据
在MVC出生的年代，手机APP的数据往往都比较简单，没有现在那么复杂，所以那时的数据解析很可能一步就解决了，所以既然有这样一个问题要处理，而面向对象的思想就是用类和对象来解决问题，显然V和M早就被定义死了，它们都不应该处理“解析数据”的问题，理所应当的，“解析数据”这个问题就交给C来完成了。而现在的手机App功能越来越复杂，数据结构也越来越复杂，所以数据解析也就没那么简单了。如果我们继续按照MVC的设计思路，将数据解析的部分放到了Controller里面，那么Controller就将变得相当臃肿。
还有相当重要的一点：Controller被设计出来并不是处理数据解析的。而是
- 管理自己的生命周期
- 处理Controller之间的跳转
- 实现Controller容器
这里面根本没有数据解析这一项，所以显然，数据解析也不应该由Controller来完成。那么我们的MVC中，M、V、C都不应该处理数据解析，那么由谁来呢？这个问题实际上在面向对象的时候相当好回答：既然目前没有类能够处理这个问题，那么就创建一个新的类出来解决不就好了？所以我们聪明的开发者们就专门为数据解析创建出了一个新的类：ViewModel。这就是MVVM的诞生。
image.png
采用双向绑定
MVVM 就是将其中的View 的状态和行为抽象化，让我们将视图 UI 和业务逻辑分开。当然这些事 ViewModel 已经帮我们做了，它可以取出 Model 的数据同时帮忙处理 View 中由于需要展示内容而涉及的业务逻辑。
其设计思想是：关注Model的变化，让MVVM框架去自动更新DOM的状态，从而把开发者从操作DOM的繁琐步骤中解脱出来！
网友评论