如何在 iOS/Swift 项目中清晰分离 ui 和业务逻辑答案

【问题标题】：How to clearly separate ui and business logic in an iOS/Swift Project如何在 iOS/Swift 项目中清晰分离 ui 和业务逻辑
【发布时间】：2019-05-16 14:09:52
【问题描述】：

我对 iOS 开发比较陌生，但在 Android/Java/Kotlin 方面拥有丰富的经验。所以我倾向于将我的 ios 项目的结构与我的 Android 项目有点相似。所以我使用的基本结构是

class MyViewController: UIViewController{
  private let viewModel = ViewModel()
} 

class ViewModel{
  func doSomethingAsync(delegate){
    SomeFactory.createService().doSomethingAsync(){
      delegate.callback
    }
  }
}

class SomeFactory{
  static func createService() -> Service {return ServiceImpl()}
}

class Service{
  func doSomething()
}

class ServiceImpl : Service{
  func doSomething(){... implementation...}
}

因此视图控制器对业务逻辑或服务一无所知，它所看到的只是数据模型。视图模型提供了两者之间的桥梁。此外，没有人可以看到ServiceImpl 类，只能通过工厂访问。这个设计是顶级的还是对于 ios 来说太“javaish”了？人们通常如何将他们的视图逻辑与应用程序的服务/业务逻辑分开？

【问题讨论】：

为了回答“将业务逻辑拉出视图控制器”，是的，我们经常这样做。是否使用 MVP、MVVM 或其他模式实现此目的取决于个人喜好。不过，工厂模式不太常见。
@Rob 感谢您的错字修复（这里已经很晚了）。此模式是 Java 中常见的抽象工厂模式的略微修改版本。我使用工厂类，因为它是定义所有服务类的一个地方 - 即：视图模型到所有服务的网关。
我对这种模式很熟悉，但我只是建议它不太常见。您问我们您的上述内容是否过于矫枉过正，我建议视图模型通常很有用，但抽象工厂的使用频率较低（或者，至少如果您关心的只是视图和业务逻辑的分离）。
我明白了。所以你通常会采用“控制器 -> 模型 -> 服务”设计而不使用工厂？

标签： ios swift architecture

【解决方案1】：

在viewController 更新您的 UI 元素。

如果不更新 ui 元素，一切（业务逻辑）肯定会转移到 viewModel

【讨论】：

您是否将所有 REST 服务内容也保留在 viewModel 中？
是的，api调用在viewModel中
说你有两个接口相同但实现不同的api服务类。您将如何使用编译器标志在两者之间切换（即：您想根据 ios 目标使用一个或另一个）？每次在视图模型中使用服务类时都必须检查，是吗？
我已经为api数据下载实现了一个单独的类。每个函数都带有完成处理程序。所以，很容易我会调用一个函数，我需要的每个函数都会调用并获取响应数据。
你没有回答我的问题，伙计。如何处理基于应用目标的 api 类的多个实现？