iOS Swift：MVP架构

苹果公司采用MVC作为iOS的官方架构模式。 哪里：

• view：是一个xib文件（或UIView子类）。
• Controller：UIViewController子类，该子类从视图接收动作和事件并对其进行更新。
• 和Models：这是数据的表示形式。

有问题的：

MVC最初打算将应用程序组件分布在不同的部分中。 但通常结果是：

缺乏分配 ：控制器最终完成了所有工作。 从处理用户交互到设置视图。 进行网络调用，数据解析等等……
这也称为Massive View Controller。

测试覆盖率低 ：除了违反单一责任原则。 控制器与视图生命周期紧密相连。 测试视图控制器成为一项艰巨的任务。

MVP作为替代：

然后，MVP体系结构可以改善这种情况。 通过添加主要组件Presenter 。

稍等一下 ！ 我知道这看起来像MVC，但有一个关键的区别：

现在， viewController被视为一个view 。 这意味着它将仅包含与视图相关的代码，仅此而已。 并且所有逻辑都将在演示者中实现。

然后，组件说明如下：

• 视图 ：现在，视图既包含视图又包含视图控制器，以及所有UI设置和事件。
• 演示者 ：演示者将负责所有逻辑，包括响应用户操作和更新UI（通过委托）。 最重要的是，我们的演示者将不会依赖UIKit 。 意味着隔离良好，因此易于测试
• 模型 ：模型角色将完全相同

请务必注意， MVP使用被动视图模式 。 这意味着所有操作都将转发给演示者。 这将使用委托触发ui更新。 因此该视图将仅传递动作并收听演示者更新。

别再说话了。 让我们弄脏双手！

让我们快速创建一个单页项目，我想你知道怎么做know

然后，我们将创建模型。 一个简单的结构称为Traffic Light，它具有两个属性。 一个用于颜色名称，另一个用于描述其交通状况。

最后是我们的traficViewController 。 现在只不过是一个视图。

这是完整的示例源代码。

结论：

这样，演示者将成为我们应用程序中的主要参与者，而无需使用UIKit框架。 并且没有创建庞大的ViewController。

同时，我们以一种易于进行单元测试的方式将逻辑与视图生命周期隔离开来。

但是，这不是一个完美的解决方案，因为演示者将要做很多工作。 那么我们将不会遵守单一责任原则。

为了解决诸如VIPER，CLEAN，MVVM之类的问题，发明了更多进化的体系结构。我将在以后的文章中尝试介绍这些体系结构。 谢谢 ！！！