iOS VIPER交互器最佳做法

Question

在iOS VIPER项目中，需要在每个模块中调用远程服务（例如，刷新令牌+检查用户登录）。 实现此需求的最佳实践是什么？

• 每个模块可以有多个交互器吗？

• 还是我们应该在每个模块（交互器）中实现相同的业务逻辑？

• 我们应该将交互器与模块（例如网络）分开，并根据需要在模块之间共享吗？

在我研究的大多数样本中，他们通常谈论的是不同的业务逻辑，而不是相同的！

Answer 1

每个人都有自己的毒蛇！！ 这是一种常见的体系结构。每个团队使用不同的方法来使用它。甚至对于一个团队，它们也可以根据项目而有所不同。我认为您需要在便利性和体系结构之间找到折衷方案。每个开发人员和每个项目在构建依赖项时都有其自己的最佳实践。 ps。根据体系结构，与网络/磁盘的所有通信均来自交互器。它可以以不同的方式组织，这与VIPER无关。网络服务的创建或交互器的重用等取决于您的.....愿望）

Answer 2

应用的每个有凝聚力的部分应该有一个 VIPER 模块，这对于具有强大的内部凝聚力是有意义的，而 VIPER 模块之间的附着力相对较小（例如，彼此之间的服务接口）。几十年来，电信软件架构一直有这样的独立模块/子系统，每个模块/子系统都是自己的 VIPER 模块（如果没有在内部分解为几个 VIPER 模块，但让我们跳过它）；它被称为 FCAPS：https://en.wikipedia.org/wiki/FCAPS，它显示了一个大型软件系统的截然不同的目的，它被分解为不同的模块：

• 通过依赖有向无环图进行故障隔离，以推动推断哪些异常症状表明出了什么问题
• 通过各种可调参数正确配置系统的配置设置（拒绝禁止的配置设置）
• 系统运作如何开始、确保连续性和终止可计费事件以产生收入的会计计费
• 系统运行如何预测接近系统性胁迫或单个组件故障（例如，资源池的成员）的趋势的性能
• 如何禁止未经授权、未经身份验证或未经资助使用系统的安全性

这不是划分最宏观 VIPER 模块的唯一可行方法，但它是经过深思熟虑的模块/子系统划分，最终几乎每个大型软件系统/应用程序都需要作为管理职责正交无论系统/应用程序的主要目的是什么，这当然是它自己的 1 个或多个 VIPER 模块，针对系统/应用程序的每个主要广泛的技术成就主题——无论最宏观的用例集合是什么（例如，将新内容创建为 1 个 VIPER 模块，将旧内容历史的可检索存档保留为另一个 VIPER 模块，从存档中删除 cruft 作为另一个 VIPER 模块，等等，其中每一个都可能有这些广泛的保护伞下有很多用例）。