MVC和MVVM

Posted 2021-09-15 火腿肠烧烤大赛冠军

M

View（视图）：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。

C

Controller（控制器）：是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

V

View（视图）：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。

MVC

MVC全名是Model View Controller，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。
首先晾图：

显而易见了：

• C层可以调用M层的数据，也可以调用V层
• M和V均不可以直接调用C层
• M和V之间不可以相互调用

View和Controller的交互

1. target-action
   Controller实际上就是靶子。只是View只负责传递事件，不负责关心靶子是谁。就像你是一个负责运货的少年，你唯一知道的是你要把货（action）交给上头（开发者）告诉你的那个收货的人（target）
2. 委托
   有两种：代理和数据源。什么是代理，就是专门处理should、will、did事件的委托，什么是数据源，就是专门处理data、count等等的委托。

Model和Controller的交互

C关注M的值是否发生了变化。如果变化则更新

MVVM

MVVM出现的原因：
在MVC出生的年代，手机APP的数据往往都比较简单，没有现在那么复杂，所以那时的数据解析很可能一步就解决了，所以既然有这样一个问题要处理，而面向对象的思想就是用类和对象来解决问题，显然V和M早就被定义死了，它们都不应该处理“解析数据”的问题，理所应当的，“解析数据”这个问题就交给C来完成了。而现在的手机App功能越来越复杂，数据结构也越来越复杂，所以数据解析也就没那么简单了。如果我们继续按照MVC的设计思路，将数据解析的部分放到了Controller里面，那么Controller就将变得相当臃肿。还有相当重要的一点：Controller被设计出来并不是处理数据解析的。

Controller能做的事情：1、self.view用来作为所有视图的容器；2、管理自己的生命周期；3、处理Controller之间的跳转；4、实现Controller容器。这里面根本没有“数据解析”这一项，所以显然，数据解析也不应该由Controller来完成。那么我们的MVC中，M、V、C都不应该处理数据解析，那么由谁来呢？这个问题实际上在面向对象的时候相当好回答：既然目前没有类能够处理这个问题，那么就创建一个新的类出来解决不就好了？所以我们聪明的开发者们就专门为数据解析创建出了一个新的类：ViewModel。这就是MVVM的诞生。

C逐渐被VM架空，C不再控制M而是交由VM控制，存在感降低变成MVVM。前端的每一个页面都是一个MVVM。
一旦在实现Controller的过程中遇到任何跟Model（或者数据）相关的问题，就找VM要答案。

文章参考：https://blog.csdn.net/u013282174/article/details/51220199