携手创作，共同成长！这是我参与「掘金日新计划 · 8 月更文挑战」的第25天，点击查看活动详情
MVC模式
MVC是软件工程中的一种软件架构模式，它把软件系统分为三个基本的部分：模型Model（负责封装数据、存储和处理数据运算等工作）、视图View（负责数据展示、监听用户触摸等工作）以及控制器Controller（负责业务逻辑、事件响应、数据加工等工作）。这种模式的目的是为了实现一种动态的程序设计，并且使程序某一部分的重复利用成为可能。还简化了后续对软件系统的修改和扩展，使程序结构更加直观，并使得程序的某一部分的复用成为可能。在其出现的一段时间后，MVC 产生了很多的变种，例如：MVP、MVVM 等架构模式。
在传统的MVC结构中，数据层在发生改变之后会通知视图层进行对应的处理，视图层能直接访问数据层。但在iOS中，Model和View之间禁止通信，必须由Controller控制器层来协调Model和View之间的变化。Controller对Model和View的访问是不受限的，但Model和View不允许直接接触控制器层，而是由多种Callbacks（回调）方式来通知控制器。
如图所示，是MVC的架构图，接下来是对架构图的解析。
Controller：
Controller对象在一个或者多个View对象和与之相对应的一个或者多个Model对象之间扮演中间人的角色。Model和View对象通过Controller来交接彼此之间的变化。Controller在程序中执行初始设置和坐标跟踪任务，也管理着其他对象的生命周期。
关于交互：Controller将用户View中的操作转变成新的数据（或者是数据更新），再与Model层进行交互。当Model中的数据改变时，Controller再次作为中间人，通知View进行更新。
Model：
关于交互：用户在View层的生成或修改数据的操作应该通过Controller对象进行交互，并且结果是创建或者更新Model对象。当Model对象发生改变的时候，通知到Controller对象，最终将对适当的View对象进行更新。
View：
在交互过程中，将交互事件通过代理、回调的方式上抛到Controller层，在Controller将事件处理完成后，将消息传递到Model层进行数据处理。当Model层有数据更新时，通过通知的方式将消息上抛给Controller层，由Controller层将数据交给View，进行View更新。
存在的问题：Controller层随业务扩展而出现无限膨胀的可能。并且当View层和Model的业务差异越大时，作为“粘合剂”的Controller层就会越复杂，因此引入MVVM来解决这一问题。
MVVM模式
MVVM（Model-View-ViewModel）的职责划分：
Model：完全独立于UI的数据处理逻辑。
View：负责视图展示，这个View可以是ViewController、View等控件。
ViewModel：Model层和View层两层间的数据转换器，并包含数据处理的业务逻辑。
在开发过程中，项目复杂度越来越高，代码量越来越大，此时MVC维护起来很吃力，因此有人想到把Controller的数据和逻辑处理部分从中抽离出来，用一个专门的对象去管理，这个对象就是ViewModel，是Model和Controller之间的桥梁。MVVM并非直接用VM替换MVC中的C，而是淡化C，因此C并没有消失只是被VM解耦。
通过ViewModel，Controller中的代码变得非常少，易于测试和维护，只需要Controller和ViewModel做数据绑定即可。
\
