大型iOS应用程序的最先进架构
介绍
我写了一篇有关将我们的iOS应用程序迁移到框架中以及该应用程序如何从此类工作中受益的文章。 本文将继续进行，并详细介绍迁移后在项目上完成的工作。 我描述了如何将内部开发的框架完美地链接在一起，以及应该遵循哪种模式才能为大型iOS应用程序实现真正的分离架构。
为我的PM记录……一切都在我的“产品空闲时间”中完成了🙂
动机
在我之前讨论的体系结构中，所有事物都属于一个适当的框架，主应用程序目标链接了所有框架，项目结构尽可能地分离，这提出了一个重要问题……将所有事物链接在一起的最佳方法是什么？ 最先进的技术是使主应用程序目标（将所有框架链接在一起的应用程序）将责任委派给框架，然后通知框架需求，例如当前正在使用的框架想要呈现属于该框架的ViewController到另一个框架。 然后将通知主应用有关此更改，并显示所需的ViewController。
我希望您可以想象这种方法的所有优点。 首先，我想提一下可重用性，想象一下Facebook发生的情况。 他们的应用程序分为两部分（Facebook，Messenger），采用这种体系结构可以轻松实现这一目标，从而同时支持两个应用程序。 由于所有内容都在一个位置链接到应用程序，因此您也可以轻松地将整个框架/功能取出并链接到多个应用程序。 不用说，在团队中，每个开发人员都可以对某个特定的框架负责，但是在上一篇文章中有更多的责任。
三层架构
在上一篇文章中，我讨论了如何将应用模块化到框架中。 在本文中，我将把我们的项目分为遵循某些严格规则的3个逻辑层，以我们在该文章中所做的工作为基础。
第一层（胶水）
第一层包括我们的主要应用目标。 它具有AppDelegate对象，初始化我们的一些服务，响应通知等等。 除此之外，它还有我们的主要应用程序协调器。 协调员的职责是处理应用程序中的转换。 它从框架功能实例化协调器，并将责任作为其子协调器传递给他们。 儿童协调员将其不负责的行为通知父母（在我们的代码库中为主要应用程序协调员）。 我们之所以将责任从孩子协调员那里转移出去，有很多原因，主要是因为我们不希望一个孩子协调员依赖于另一个孩子协调员，如上图所示。
第二层（功能）
第二层具有我们的所有功能，例如发布项目，管理页面，聊天等。 这些框架中的每个框架都实现自己的协调器，该协调器将在第一层中实例化。 理想情况下，协调员应该是框架之外唯一公开可见的对象。 通过将框架协调器作为唯一可见的对象，我们确保这是与该功能进行交互的唯一方法。 第二层遵循严格的规则，不得链接第二层中的任何其他框架。 这样做的原因是要使功能与其他功能保持脱钩状态，因此可以很容易地将其带入或带出项目。 但是，第二层可以链接第三层的任何框架，并且被第一层链接。 话虽如此，第二层的框架可能需要具有一些共享的依赖关系，例如，功能框架很可能需要访问网络或持久性，这就是第三层的目的。
第三层（核心）
第三层是应用程序的核心，例如模型，网络，持久性，本地化等。第二层的框架由第二层链接，没有任何限制。 但是，与第二层不同，第三层的框架可以相互链接。 要避免在第三层建立这种联系将是极其困难的。 例如，您的网络框架（如持久性框架）将要使用模型框架……您可以想到许多类似的情况。 一种可能的解决方案是创建第四层。 只有第三层的共享框架才在第四层。 这可能是一个很好的解决方案，但是我们发现它有些过分设计。
这是一个工作区外观的示例。
实作
这是一个看起来很幼稚的例子。 在代码中，我使用术语流程代替协调器，因为根据我的观点，它是一个更准确的术语。 让我们从为Flow定义协议开始。 您可以在此处查看完整的演示。
现在，让我们看一下主要的AppFlow（AppCoordinator）。
最后，从其中一个框架实施子流程。
协调器模式已为人所知已有一段时间，有很多文档可以激发您的灵感。 我想在这里指出，我已经看到了一些实现，其中协调器接管了模型并正在获取数据或执行其他一些控制器/视图模型作业。 不用说，协调器是为应用程序流而设计的，这就是工作。 协调器实现的方法应仅从对您的体系结构负责的任何事物（视图模型，视图控制器等）中获取已经计算/下载的值。 换句话说，保持固体😉
结论
本文介绍了如何将内部开发的框架完美地链接在一起，以及应该遵循哪种模式才能在iOS上实现真正的分离架构。 我写了这两篇文章是因为不确定这种设置将在一开始将我们引向何方。 幸运的是，一切看起来都很好，并且运作良好。 我已经在上一篇文章中提到过，对于小型应用程序来说，这种体系结构有些过大，但是在开始一个新的大型项目之前，可能需要考虑一下。
如果您觉得这些文章有用，请发表评论或给我鼓掌（…或50）🙂