iOS VIPER交互器最佳实践

Question

在iOS VIPER项目中，需要在每个模块中调用远程服务(例如刷新令牌+检查用户登录)。实现这一需要的最佳做法是什么？

• 每个模块可以有多个交互者吗？
• 还是应该在每个模块(interactor)中实现相同的业务逻辑？
• 我们是否应该将交互行为者从模块(如网络)中分离出来，并根据需要在模块之间共享？

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

Answer 1

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

Answer 2

每个应用程序的内聚部分应该有一个VIPER模块，这样才有意义具有强大的内部内聚力，并且在VIPER模块之间的粘着性相对较小(例如，服务接口彼此之间)。几十年来，电信软件体系结构一直有这样一个独立的模块/子系统，每个模块都是各自的VIPER模块(如果不是将其内部分解为几个VIPER模块，但让我们跳过这一点)；它被称为FCAPS：https://en.wikipedia.org/wiki/FCAPS，它展示了一个大型软件系统被分解成不同的模块的截然不同的用途：

• 通过依赖有向无环图进行故障隔离，从而推断出异常症状表明出了什么问题
• 配置-通过各种可调参数正确配置系统的设置(拒绝禁止的配置-设置)
• 会计-系统的运作如何开始，确保连续性，并退休的计费事件，以产生收入。
• 系统运行如何预测接近系统压力或单个组件故障的趋势(例如，资源池的成员)的性能
• 禁止未经授权或未经认证或无资金使用系统的安全

这不是唯一可以想象的划分最宏观的VIPER模块的方法，但这是一个经过深思熟虑的划分模块/子系统，最终几乎每个大型软件系统/应用程序都需要与系统/应用程序的主要目的相正交的管理职责，这当然是它自己的一个或多个VIPER模块，一个用于系统/应用程序的每个主要的技术成就主题--无论是哪种最宏观的用例--用例都是(例如，作为一个VIPER模块创建新的东西，作为另一个VIPER模块保留一个可检索的旧东西的档案，删除cruft作为另一个毒蛇模块的档案，等等，其中每一个可能有相当多的用例在这些大雨伞下)。