MVP vs MVC vs MVVM vs VIPER。 什么更适合 iOS 开发？

就像每个房子都有一个坚实的地下室，每个软件项目都有一个构建它的软件架构，每个项目都有自己的应用程序结构。 架构模式的类型可能会有所不同，但最常用的有 4 种——整个 IT 界不断批评但同时继续使用的模式： MVC、MVP、MVVM 和 Viper （最后一种作为 iOS 架构模式居多） . 本文将进一步介绍这些模式的比较以及为每个 Swift 编写的项目案例选择更合适的模式。

按照时间顺序，一旦第一个软件设计模式出现，那些 ios 开发架构模式的常见问题很快就出现了。

例如，服务器-客户端通信的问题——一个人如何与另一个人交互？ 或者不同的 - 将应用程序的业务逻辑与应用程序内的逻辑分离的问题； 这个在应用程序架构方面应该如何执行？ 由于它们，不同架构层的各种设计模式已经见识过世界； 其中最著名的是：

- 单例设计模式。

这种模式允许一个类只应用于一个对象，当系统批准有限数量的实例（或仅一个实例）时，此选项有用。

- 装饰器设计模式。

与单例相反，这种模式（也称为 Wrapper 和 Adapter 模式）允许将特定行为添加到单个对象（静态或动态），并且所有这些都不会影响其他对象的行为一个共享一个类。

- 桥梁设计模式。

由臭名昭著的四人帮的作者《设计模式》首先介绍，这种架构模式“使用封装、聚合，并且可以使用继承将职责分离到不同的类中。当一个类经常出现时，面向对象的特性编程变得非常有用，因为只需对程序的先验知识最少，就可以轻松更改程序代码。 [来源：维基]

尽管这些模式大不相同，但代码编写者的共同问题在每个人身上都发生了。 例如，Singleton 的“质量”。 Singleton 过于全局化，因为您的代码的依赖关系深深地隐藏在您的应用程序中，而不是在接口中公开。 这就是为什么在软件开发过程中不断出现新模式的原因。

4 种最常用的模式是MVC、MVP、MVVM 和 VIPER （主要用于 iOS）。

按照列出的顺序开发，它们都有自己的优点和缺陷，引起了许多关于每个应用程序的争议。 多关注他们实施的最佳实践可能会使事情变得更清楚。

MVC模式

所有软件模式的祖父，于 1970 年代初由挪威计算机科学家 Trygve Reenskaug 首次引入，模块 - 视图 - 控制器，广为人知的 MVC，是面向对象编程的首批模式方法之一。

View 部分负责为系统用户显示所有内容（移动或 Web 应用程序的界面等）。 模型一般负责数据库、业务实体和其余数据。 反过来，控制器调节模型的工作，提供给数据库的数据，从提到的数据库显示到视图部分，反之亦然。

无论 MVC 模型多么通用，两个最大的竞争对手——苹果和谷歌都有自己的模式来表示模型 - 视图 - 控制器系统。 Apple 系统的问题在于 View 和 Controller 部分之间的紧密连接，紧密到几乎将 View 和 Controller 结合在一起，而将 Model 部分分开。

因此，这会导致测试过程不佳 - 只能检查模型，根本无法测试 V&C（由于它们之间的紧密连接）。

当涉及到软件时，控制器和视图段之间的强大连接被证明是真正“不健康”的，因此一种新模式很快就出现了。

MVP 模式。

我们中的许多人都在最小可行产品的上下文中听说过这个捷径，但就软件工程而言，它意味着不同的东西。 Model View Presenter 模式的关键点很少，在它和 MVC 之间形成了巨大的鸿沟：

MVP模型

• 视图与模型的耦合更松散。 Presenter 负责将模型绑定到视图。

• 更容易进行单元测试，因为与视图的交互是通过接口进行的。

• 通常查看到演示者 = 一对一映射。 复杂的视图可能有多个演示者。

MVC模式

• 控制器基于行为，可以跨视图共享

• 可以负责决定显示哪个视图
  [来源：基础设施]

在这种安排中，Model 的功能保持不变； Presenter分别负责业务逻辑。 V 部分是特别有趣的部分 - 因为它分为两部分 View 和 View Controller，它们是交互的权威。 当出现 MVVM vs MVC 问题时，这种类型的系统解决了 MVC 模式中曾经存在的“重度依赖”视图和控制器模式的问题。

在这种情况下，测试障碍也得到了解决，因为模型、具有用户交互的视图和演示器部件 - 所有这些都可以进行测试。
尚存在的不便在于 Presenter 的部分——但过于庞大，但考虑到了所有现有的业务逻辑。 这就是为什么下一幕开始发挥作用的原因，名为……

MVVM 模式

2005 年，Microsoft 的架构师之一 John Gossman 创建了Model-View-ViewModel软件架构模式。 MVVM模型的三个核心组件分别是：
模型是“应用程序域模型的实现，包括数据模型以及业务和验证逻辑。 模型对象的示例包括存储库、业务对象、数据传输对象 (DTO)、普通旧 CLR 对象 (POCO) 以及生成的实体和代理对象。” [来源：微软]

视图再次是用户能够看到的一切 - 屏幕上所有内容的布局、结构和外观。 基本上，在应用程序中，它将是应用程序的页面。 View 只对 ViewModel 获取和发送更新，不包括这部分和 Model 本身之间的所有通信。

ViewModel 应该是 View 和 Model 系统组件之间的“互连链”，它的主要功能是处理 View 的逻辑。 通常，视图模型通过调用模型类中的方法与模型交互。 正如微软所说，视图模型然后以视图可以轻松使用的形式提供来自模型的数据。

MVC 和 iOS MVVM 的主要区别在于，MVVM 的分布模式比之前列出的 MVC 更好，但与 MVP 相比，它也大量过载。 在这里测试是一个特别重要的问题，因为虽然简单地编写代码，但您不能保证整个项目会正常运行——从光明的角度来看，测试有助于确保它会正常运行。

下一个架构模式的演变最近已经发布，现在是最新鲜的软件架构方法。

iOS VIPER 架构

为了寻找最佳的架构解决方案，世界各地的 iOS 开发人员遇到了所谓的“清洁架构”方法，由鲍勃叔叔在 Clean Coders 上引入，这是一个为全球软件专业人士提供培训课程的知名平台。

Clean Architecture 将应用程序的逻辑结构拆分为多个职责级别。 反过来，这种“分离”解决了紧密的依赖问题并提高了所有级别的测试可用性。

ios开发的VIPER

VIPER 是针对 iOS 构建的应用程序的 Clean Architecture 的实现。 作为所有模式名称的通用规则，它也是 View、Interactor、Presenter、Entity 和 Routing 的反义词。 VIPER 的每个部分都负责特定的元素，特别是：

1. 视图负责反映用户对界面所做的操作

2. 在 VIPER 模式中，Presenter 的职责非常有限——它接收来自 Entity 的更新，但不向它发送任何数据；

3. 交互器是系统中实际与实体对应的部分。 该方案按以下方向工作：Presenter 将 View 模型中的更改通知给 Interactor，然后 Interactor 联系 Entity 部分，并将从 Entity Interactor 接收到的数据返回给 Presenter，Presenter 命令 View 为用户镜像。 所有数据模型、所有实体和所有网站都连接到交互器部分。

4. 实体由由交互器控制的对象（标题、内容等）组成。它从不直接与演示器交互，仅通过 I 部分。

5. 路由（或有时称为线框）负责所有屏幕之间的导航，并且本质上是路由。 Wireframe 控制 UIWindow、UINavigationController 等对象。

尤其是在 iOS 架构系统中，它都是建立在一个叫做 UIkit 的框架之上的，它包含了 Apple MVC 的所有组件，但没有一个紧密的联系，这种联系曾经让程序员发疯。

一旦涉及到单元测试，VIPER 模块也很有用，因为伟大的模式的分布让您可以测试所有可用的功能。 在许多方面，这是开发人员在使用以前的 MVC、MVP 和 MVVM 软件模式时面临的主要困难。

为这一切加冕。

所有这 4 种软件设计模式通常都被称为 iOS 开发的最佳架构模式之一，尽管它们都不太理想，而且绝对不能普遍用于您要开发的每个项目。 令人沮丧的是，以下是每个模式存在的问题的简短列表：

• MVC、MVP、MVVM——它们都有这个“紧密连接”的问题，这使得在开发中引入更新并在之后测试它们是一项非常艰巨的任务。

• VIPER vs MVVM, MVC or MVP ，被认为是一个胜利的案例； 尽管尽管它具有高度的灵活性和出色的可测试性，但也有许多难以产生的细微差别。

有100%固溶体吗？ 并非如此，但对于您的每个项目，这 4 种 iOS 应用程序模式之一可能正是您所需要的。 如果不是，那么两者的混合将是。 或者甚至可能是三个。 据说财富偏爱大胆的人，那么您为什么不大胆地玩弄软件设计模式呢？

由 Max Mashkov 和 Elina Bessarabova 撰写。