大家好，我是本期栏目编辑小友，现在为大家讲解iOS开发几个架构的对比问题。
在iOS的开发中，苹果定义了一套MVC软件架构。前几天，同事们谈到了MVC、MVC、MVVM等架构的区别。今天，我也在这里给出我自己对此的理解。
手动音量调节
基本MVC模式
下图是基本的MVC(模型-视图-控制器)模式结构图，可以分为模型、视图和控制器三部分。它在MVC模式中的作用如下：
模型：模型管理应用程序的数据，响应对其状态信息的请求(通常来自视图)，并响应更改状态的指令(通常来自控制器)。
视图：显示视图管理数据。
控制器：控制器解释用户的输入，并通知模型和视图更新状态。
其中，视图和控制器依赖于模型，而模型不依赖于视图和控制器。这种设计模式的优点是它允许模型独立于视图，因此它可以独立构建和测试。
此外，根据模型的具体实现，还可以进一步分为主动模型和被动模型。
被动模型MVC模式
当只有一个控制器控制模型时，可以采用被动模型。控制器定义模型，并在模型改变时通知视图，然后视图更新模型。在这种情况下，模型完全独立于视图和控制器。实际上，被动模型MVC模式是基本的MVC模式。
活动模型MVC模式
当模型状态在不受控制器干扰的情况下发生变化时，使用活动模型。当其他来源正在更改数据并且必须立即在视图中反映数据时，可能会发生这种情况。
为了实现主动模型，观察者模式通常用于提供一种机制来提醒其他对象状态的变化，并避免引入依赖关系。每个视图实现观察者界面，并向模型注册。当模型发生变化时，模型将遍历所有注册的观察者，并将相关变化通知他们。这种方法通常被称为“发布-订阅”。模型从不需要关于任何视图的任何信息。实际上，当控制器需要被告知模型的变化时(例如，启用或禁用菜单选项)，所有控制器必须实现观察者界面并订阅模型的变化。
传统MVC
上述主动模型MVC模式通过添加观察者模式进行了改进。事实上，随着业务需求的变化，MVC模式通过增加一些更基本的设计模式，已经演变成了经典的MVC模式。这些基本模式共同定义了MVC应用程序独特的功能分离和通信路径。
上图展示了传统的MVC设计模式，通过Composition、Strategy、Observer等基础设计模式的协同实现。用户在复合结构的某个级别操作视图来生成事件。控制器接收并解释该事件。这个过程通过策略模式来实现，策略模式可以是请求模型对象更新其状态的消息，也可以是请求视图对象更新其行为或外观的消息。当状态改变时，模型通知所有注册为观察者的对象。如果观察者是一个对象，它的外观可以相应地更新。
苹果MVC
认为在苹果传统的MVC模式下，View通过Observer模式直接观察Model对象，获取相关通知，但这种设计会导致View和Model对象不能被广泛重用，因为View和被观察的Model之间存在耦合关系。因此，除了视图和模型是分开的之外，苹果的MVC与传统的MVC基本相同。
在iOS中，UIViewController和UIVi
ew是一一对应的。随着业务的深入，MVC最终一点点变成了Massive-View-Controller。
MVP
MVP（Modell-View-Presenter）模式就是为了解决MVC中Controller越来越臃肿的问题，进一步明确代码分工。MVP与苹果版MVC非常相似，但是它们的从属关系有所不同（实线表示持有）。如下图所示，MVP模式中View持有Presenter，Presenter持有Model，View不能直接访问Model；而MVC模式中Controller持有View和Model。
通过修改从属关系，可以真正意义上实现将UI逻辑和数据逻辑隔离，而隔离之后就可以方便地对数据逻辑部分进行单元测试。
在iOS中，MVP的实现一般如下图所示。
MVVM
MVVM（Model View View-Model）就是为了解决MVP中Presenter过于臃肿的问题。MVVM的思想是将Controller中UI控制逻辑与业务逻辑进行分离，并抽离出一个View-Model来完成UI控制的逻辑。而Controller只需要负责业务逻辑即可。如下图便是MVVM的结构图。
通常，View-Model可以调用Model定义的方法，从Model中获取数据以用于View，并对数据进行预处理，使View可以直接使用。View又可以向View-Model发出用户的操作命令，从而更改Model。MVVM实现了一种双向绑定机制。
在iOS中，MVVM的实现一般如下图所示。
MVVM的优点在于：降低了View和Model之间的耦合；分离了业务逻辑和视图逻辑。缺点在于：View和Model双向绑定导致bug难以定位，两者中的任何一方出现问题，另一方也会出现问题；增加了胶水代码。