【问题标题】:VIPER modules dependenciesVIPER 模块依赖项
【发布时间】:2018-12-20 11:29:12
【问题描述】:

我一直在从事一个个人项目,以便更好地了解 VIPER 架构。我真的很喜欢我可以将模块分开,使代码更简洁的方式。

对于模块依赖,我还是有些疑惑:

我有一个模块负责显示基于用户数据的一些统计数据,另一个模块负责显示基于统计数据的一些数据预测。

然后,我的 ProjectionsInteractor 需要从 StatisticsInteractor 中获取一些数据,因为我不想重复实现相同的东西两次。

我已经有一个 DataManager 层,基本上是一个 CoreDataManager,但那里没有任何逻辑。它只是被 Interactors 用来检索和操作一些数据,而不知道 Persistence 的任何细节。

我应该把从多个交互者中提取出来的共性放在哪里?有什么不同吗:

  • 共性是否与交互器的核心{数据存储、网络、传感器}数据采集/存储目的相关
  • 共性是否与要对从 {data-store、networking、sensors} 获取的数据强制执行的业务规则相关?

【问题讨论】:

  • 我无法理解您的困惑。对在两个模块中使用一个交互器感到困惑??
  • 我的问题是:可以从另一个交互器调用一些交互器的方法吗?因为我觉得这违反了模块独立性
  • 我想是的。我会创建一个不同的类来获取或处理您用作统计信息的数据,并使用该类来提供关于这两个不同交互器的数据。我不会为两个模块创建一个交互器
  • 这是否意味着将整个业务逻辑移到这个新类中(一个助手?)并基本上使统计交互器成为一个简单的调度程序?
  • 是的。我会以这种方式实现它。因为,它不违反 VIPER 的任何政策

标签: ios swift architecture viper-architecture interactors


【解决方案1】:
  • 如果共性本质上是应用程序域业务规则,则将共性分解为将其移至演示者区域,这是所有应用程序域业务规则都将存放在 VIPER 架构中的地方。
  • 但是,如果共性本质上是以交互器为中心的,则不是让一个交互器调用另一个交互器的方法,而是将交互器之间的共性分解到交互器区域内的一个库中,多个交互器将调用该库。该库可以采用多种形式:实用程序层(来自更传统的时代)或需要继承共性的交互器协议。

TL;DR:排除共性。将分解出来的共性放在哪里取决于共性是什么主题/特征。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-04-17
    • 2019-02-12
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多