带有swift的依赖注入，带有两个UIViewControllers的依赖图，没有公共父级

Question

我们如何在不使用框架的情况下应用依赖注入，当我们有两个层次结构非常深的UIViewController并且它们都需要相同的依赖关系来保存状态时，那两个UIViewControllers它们没有共同的父代。

例：

VC1 - > VC2 - > VC3 - > VC4

VC5 - > VC6 - > VC7 - > VC8

让我们看看VC4和VC8他们都需要拥有当前用户的UserService 。

请注意，我们要避免使用Singleton。

是否有一种优雅的方式来处理这种DI情况？

经过一番研究，我发现有些提到Abstract Factory ， Context interfaces ， Builder ， strategy pattern

但我找不到如何在iOS上应用它的示例

Answer 1

好的，我会试一试。

你说“没有单身人士”，所以我在下面排除了这一点，但也请看这个答案的底部。

Josh Homann的评论已经成为一个解决方案的好指针，但我个人对协调器模式有疑问。

正如Josh正确地说视图控制器不应该（很多）知道彼此[1]，但那么如何协调器或任何依赖传递/访问？ 有几种模式可以提示如何，但大多数都有一个基本上违背你的要求的问题：它们或多或少使协调者成为一个单身人士（或者本身或者像AppDelegate这样的另一个单身人士的财产）。 协调员通常也会成为一个单身因子（但并非总是如此，而且并非必须如此）。

我倾向于做的是依赖于简单的初始化属性或 （最常见的） 惰性属性和面向协议的编程。 让我们构建一个示例： UserService应该是定义您的服务所需的所有功能的协议， MyUserService它的实现结构。 假设UserService是一个设计构造，它基本上用作某些用户相关数据的getter / setter系统：访问令牌（例如保存在钥匙串中），一些首选项（头像图像的URL）等。 在初始化时， MyUserService还准备数据（例如，从远程加载）。 这将用于几个独立的屏幕/视图控制器，而不是单例。

现在，每个对访问此数据感兴趣的视图控制器都有一个简单的属性：

lazy var userService: UserService = MyUserService()

我保持公开，因为这允许我在单元测试中轻松地模拟/存根（如果我需要这样做，我可以创建一个模拟/存根行为的虚拟TestUserService ）。 实例化也可以是一个闭包，如果init需要参数，我可以在测试期间轻松切换出来。 显然，根据对象实际执行的操作，属性甚至不一定需要lazy 。 如果提前实例化对象没有任何危害（记住单元测试，还有传出连接），只需跳过lazy 。

诀窍是明显的设计UserService和/或MyUserService的方式创建它的多个实例时不会导致问题 。 但是，我发现90％的时间这不是真正的问题，只要实例应该依赖的实际数据保存在其他地方，在单一的事实中，如钥匙串，核心数据堆栈，用户默认值或远程后端。

我知道这是一种解决问题的答案，因为在某种程度上我只是说描述了一种方法（至少是其中的一部分）。 但是我发现这是在Swift中处理依赖注入的最通用和最简单的形式。 协调器模式可以与它正交使用，但我发现它在日常使用中不那么“像苹果一样”。 它确实解决了一个问题，但主要是你得到的问题，你没有正确使用故事板（特别是：只是将它们用作“VC repos”，从那里实例化并在代码中转换自己）。

[1]除了一些基本和/或次要的东西，你可以在完成处理程序或prepareForSegue传递。 这是有争议的，取决于你遵循协调员或其他模式的严格程度。 就个人而言，我有时会在这里采取捷径，只要它不会膨胀并且变得混乱。 一些弹出式设计更简单。

---

作为结束语，“请注意我们要避免使用Singleton”这一短语以及您对该问题的评论给我的印象是，您只是在没有充分考虑其基本原理的情况下遵循该建议。 我知道“单身人士”经常被认为是一种反模式，但正如判断错误通知一样。 单例可以是一个有效的架构概念（您可以通过它在框架和库中广泛使用的事实来看到）。 关于它的坏处只是它经常诱使开发人员在设计中采用快捷方式并将其作为“对象存储库”滥用，这样他们就不需要考虑实例化对象的时间和地点。 这导致了混乱和模式的坏名声。

UserService ，取决于您的应用程序中实际执行的操作， 可能是单身人士的理想选择。 我个人的经验法则是：“如果它管理一些单一且独特的东西的状态，就像在特定时间只能处于一种状态的特定用户”，我可能会选择一个单身人士。

特别是如果你不能按照我上面概述的方式设计它，即如果你需要内存中的单数状态数据 ，单例基本上是一种简单而正确的方法来实现它。 （即使然后使用（懒惰）属性也是有益的，您的视图控制器甚至不需要知道它是否是单例，并且您仍然可以单独存根/模拟它（即不仅仅是全局实例）。）

Answer 2

根据我的理解，这些是您的要求：

1. VC4和VC8必须能够通过UserService类共享状态。
2. UserService不能是单例。
3. 必须使用依赖注入将UserService提供给VC4和VC8。
4. 不得使用依赖注入框架。

在这些限制内，我建议采用以下方法。

定义具有用于访问和更新状态的方法和/或属性的UserServiceProtocol 。 例如：

protocol UserServiceProtocol {
    func login(user: String, password: String) -> Bool
    func logout()
    var loggedInUser: User? //where User is some model you define
}

定义实现协议的UserService类并将其状态存储在某处。

如果状态只需要在应用程序运行时持续，您可以将状态存储在特定实例中 ，但此实例必须在VC4和VC8之间共享。

在这种情况下，我建议在AppDelegate创建并保存实例，并将其传递给VC链。

如果状态需要在启动应用程序之间持续存在，或者您不想通过VC链传递实例，则可以将状态存储在用户默认值，Core Data，Realm或外部的任何数量的位置班级本身。

在这种情况下，您可以在VC3和VC7中创建UserService并将其传递给VC4和VC8。 VC4和VC8会有var userService: UserServiceProtocol? 。 UserService需要从外部源恢复其状态。 这种方式即使VC4和VC8具有不同的对象实例，状态也是相同的。

Answer 3

首先，我相信你的问题有一个错误的假设。

您可以定义VC'c层次结构：

例：

VC1 - > VC2 - > VC3 - > VC4

VC5 - > VC6 - > VC7 - > VC8

然而，在iOS上（除非你使用一些非常奇怪的黑客），在某些时候总会有一个共同的父母，如导航控制器，标签栏控制器，主细节控制器或页面视图控制器。

所以我假设一个正确的方案可能看起来像，例如，像这样：

标签栏控制器1 - >导航控制器1 - > VC1 - > VC2 - > VC3 - > VC4

标签栏控制器1 - >导航控制器2 - > VC5 - > VC6 - > VC7 - > VC8

我相信这样看是很容易回答你的问题。

现在，如果你要求一个意见是什么是在iOS上处理DI的最佳方式，我会说没有最好的方法。 但是我个人喜欢坚持对象不应该对自己的创建/初始化负责的规则。 所以像

private lazy var service: SomeService = SomeService()

是不可能的。 我更喜欢需要SomeService实例的init或者至少（对于ViewControllers来说很容易）：

var service: SomeService!

这样你就可以将获取正确模型/服务等的责任传递给实例的创建者，同时你可以通过一个简单但重要的假设来实现你的逻辑，即你拥有所需的一切（或者你让你的课程早期失败） （例如通过使用力展开），这在开发期间实际上是好的）。

现在，你如何获取这些模型 - 是通过初始化它们，传递它们，使用提供者，容器，协调器等单独一个 - 它完全取决于你，也应该依赖于项目的复杂性，客户需求等因素，无论你使用什么工具 - 所以一般来说，只要你坚持良好的OOP实践，任何工作都可以。

Answer 4

这是我在一些可能对您有帮助的项目中使用的方法。

1. 通过ViewControllerFactory中的工厂方法创建所有视图控制器。
2. ViewControllerFactory有自己的UserService对象。
3. 将ViewControllerFactory的UserService对象传递给需要它的那些视图控制器。

这是一个温和的例子：

struct ViewControllerFactory {

private let userService: UserServiceProtocol

init(userService: UserServiceProtocol) {
    self.userService = userService
}

// This VC needs the user service
func makeVC4() -> VC4 {
    let vc4 = VC4(userService: userService)
    return vc4
}

// This VC does not
func makeVC5() -> VC5 {
    let vc5 = VC5()
}

// This VC also needs the user service
func makeVC8() -> VC8 {
    let vc8 = VC8(userService: userService)
    return vc8
}
}  

ViewControllerFactory对象可以实例化并存储在AppDelegate中。

这是基础知识。 另外，我还会看一下以下内容（另请参阅其他答案，这些答案在这里提出了一些很好的建议）：

1. 创建UserService符合的UserServiceProtocol。 这样可以轻松创建用于测试的模拟对象。
2. 查看协调器模式以处理导航逻辑。

Answer 5

我发现协调器/路由器设计模式最适合注入依赖关系和处理应用程序导航。 看看这篇文章，它帮助了我很多https://medium.com/@dkw5877/flow-coordinators-333ed64f3dd

Answer 6

我试图解决这个问题，并在这里上传了一个示例架构： https ： //github.com/ivanovi/DI-demo

为了更清楚，我使用三个VC简化了实现，但该解决方案可以适用于任何深度。 视图控制器链如下：

Master - > Detail - > MoreDetail（注入依赖项）

建议的体系结构有四个构建块：

• 协调器存储库：包含所有协调器和共享状态。 注入所需的依赖项。

• ViewController Coordinator：执行导航到下一个ViewController。 协调器拥有一个工厂，可以生成VC所需的下一个实例。

• ViewController工厂：负责初始化和配置特定的ViewController。 它通常由协调员拥有，并由CoordinatorRepository注入协调器。

• ViewController：要在屏幕上显示的ViewController。

Nb：在示例中，我返回新创建的VC实例只是为了生成示例 - 即在现实生活中，不需要返回VC。

希望能帮助到你。

Answer 7

let viewController = CustomViewController()
viewController.data = NSObject() //some data object
navigationController.show(viewController, sender: self)


import UIKit

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?
    var appCoordinator:AppCoordinator?

    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplicationLaunchOptionsKey: Any]?) -> Bool {
        // Override point for customization after application launch.
        window = UIWindow(frame: UIScreen.main.bounds)
        window?.rootViewController = UINavigationController()
        appCoordinator = AppCoordinator(with: window?.rootViewController as! UINavigationController)
        appCoordinator?.start()
        window?.makeKeyAndVisible()
        return true
    }
}