本文为Resolver-Swift版超轻依赖注入/服务定位器框架中的链接。

也是GitHub 中 Resolver: Introduction的翻译。

定义

Resolver是Swift依赖注入框架，支持控制设计反转模式（Inversion of Control design pattern）。
除了计算机科学定义，依赖注入基本上归结为：

| 给一个对象提供它需要做的事情。

依赖注入允许我们编写松散耦合的代码，因此，更易于重用、模拟和测试。

简单的例子

这里有一个需要与NetworkService通信的对象。

class MyViewModel {
    let service = NetworkService()
    func load() {
        let data = service.getData()
    }
}

该类被认为与它的依赖项NetworkService紧密耦合。

问题是MyObject总是这样创建它自己的NetworkService类型的服务。

但是如果我们希望MyViewModel从磁盘中提取数据呢？如果我们想在代码中的其他地方重用MyViewModel，或者在另一个应用程序中，让它提取不同的数据呢？

如果我们想对MyViewModel的测试结果进行模拟要怎么做呢？
或者为了达到质量保证的目的，要让应用程序完全运行在mock数据上要怎么做呢？

注入

现在，考虑一个依赖于传递给它的NetworkService实例的对象，使用我们的DI(Dependency Injection依赖注入)类型的术语进行属性注入。

class MyViewModel {
    var service: NetworkServicing!
    func load() {
        let data = service.getData()
    }
}

MyViewModel现在依赖于预先设置的网络服务，而不是直接实例化NetworkService本身的副本。

此外，MyViewModel现在使用一个名为NetworkServicing的协议，它反过来定义了一个getData（）方法。

这两个变化使我们能够实现上述所有目标。

将NetworkServicing的正确实现传递给MyViewModel，然后可以从网络、缓存、磁盘上的测试文件或模拟数据池中提取数据。

很好。但是这种方法只是做到了把罐子踢得更远吗？

如何获取MyViewModel以及MyViewModel如何获得NetworkService的正确版本？我不需要自己创建它并设置它的属性吗？

好吧，你可以，但是更好的答案是使用依赖注入。

注册

依赖注入分为两个阶段：注册 和 解析。

注册包括注册我们需要的类和对象，以及在需要时提供一个工厂闭包来创建一个实例。

Resolver.register { NetworkService() as NetworkServicing }

Resolver.register { MyViewModel() }.resolveProperties { (_, model) in
    model.service = optional() // note NetworkServicing was defined as an ImplicitlyUnwrappedOptional
}

上面的内容看起来有点复杂，但实际上相当简单。

首先，我们注册了一个工厂（闭包），它将在需要时创建NetworkService的实例。使用工厂返回的结果类型自动推断正在注册的类型。

因此，我们创建了一个NetworkService，但是我们实际注册了协议NetworkService。

类似地，我们注册了一个工厂，以便在需要时创建MyViewModel，还添加了resolveProperties闭包来解析其服务属性。

解析

一旦注册，任何对象都可以要求Resolver提供（解析）该类型的对象。

var viewModel: MyViewModel = Resolver.resolve()

为什么这么麻烦？

所以我们注册了一个工厂，并要求Resolver解析它和它的工作..但是为什么要制造这些额外的麻烦呢？

为什么我们不直接实例化MyViewModel并完成它呢？

var viewModel = MyViewModel()
viewModel.service = NetworkService()

好吧，这是导致这个‘坏主意’的产生的几个原因，但让我们从两个方面开始：

首先，如果NetworkService反过来需要其他类或对象来完成它的工作，会发生什么情况？如果这些对象需要引用其他对象、服务和系统资源，会发生什么？

var viewModel = MyViewModel()
viewModel.service = NetworkService(TokenVendor.token(AppDelegate.seed))

你只需要构造所需的对象...构建所需的对象...来构建您最初真正想要的对象的单个实例。

这些附加对象称为依赖项。

其次，更糟的是，构造类现在知道MyViewModel和NetworkService的内部和需求，还知道TokenVendor及其需求。

当它真正想做的只是和一个MyViewModel交谈时，现在却与所有这些类的行为和不同的实现紧密耦合...

ViewController、ViewModel和服务。哦，天的天哪。

为了演示，让我们用一个更复杂的例子。

这里有一个名为MyViewController的UIViewController，它需要一个XYZViewModel的实例。

class MyViewController: UIViewController {
    var viewModel: XYZViewModel!
}

XYZViewModel需要一个实现XYZFetching协议的对象实例，一个实现XYZUpdating的对象实例，它还需要访问XYZService。

反过来，XYZService需要对XYZSessionService的引用来完成其工作。

class XYZViewModel {
    private var fetcher: XYZFetching
    private var updater: XYZUpdating
    private var service: XYZService

    init(fetcher: XYZFetching, updater: XYZUpdating, service: XYZService) {
        self.fetcher = fetcher
        self.updater = updater
        self.service = service
    }
    // Implmentation
}

class XYZCombinedService: XYZFetching, XYZUpdating {
    private var session: XYZSessionService
    init(_ session: XYZSessionService) {
        self.session = session
    }
    // Implmentation
}

struct XYZService {
    // Implmentation
}

class XYZSessionService {
    // Implmentation
}

请注意，XYZViewModel和XYZCombinedService的初始值设定项都传递了它们执行任务所需的对象。使用依赖注入行话，这被称为初始化或构造函数注入，这是对象构造的推荐方法。

注册

让我们使用Resolver来注册这些类。

这里我们用ResolverRegistering协议扩展了基本解析器类，它几乎只告诉Resolver我们已经添加了registerAllServices（）函数。

registerAllServices函数在Resolver第一次被要求解析服务时自动调用，实际上是执行解析系统的一次性初始化。

extension Resolver: ResolverRegistering {
    public static func registerAllServices() {
        register { XYZViewModel(fetcher: resolve(), updater: resolve(), service: resolve()) }
        register { XYZCombinedService(resolve()) }
            .implements(XYZFetching.self)
            .implements(XYZUpdating.self)
        register { XYZService() }
        register { XYZSessionService() }
    }
}

因此，上面的代码向我们展示了如何注册XYZViewModel、协议XYZFetching和xyzupdate、XYZCombinedService、xyz服务和XYZSessionService。

了解有关注册的详细信息

解析

现在我们已经注册了应用程序将要使用的所有对象。但是这个过程是怎么开始的呢？谁先做出决定的？

好吧，MyViewController是想要一个XYZViewModel的对象，所以让我们用下面的方法重写下...

class MyViewController: UIViewController, Resolving {
    lazy var viewModel: XYZViewModel = resolver.resolve()
}

采用Resolving protocol将默认解析器实例注入MyViewController（接口注入）。在该实例上调用resolve允许它从解析器请求XYZViewModel。

Resolver处理请求，找到正确的工厂来创建XYZViewModel，并告诉它这样做。

XYZViewModel工厂反过来触发它所需类型的解析（XYZFetching、XYZUpdating和XYZService），等等，一直到链的下游。最终，XYZViewModel工厂获得所需的一切，返回正确的实例，MyViewController获得其视图模型。

MyViewController不知道XYZViewModel的内部结构，也不知道XYZFetcher、XYZUpdater、XYZService或XYZSessionService。

也不需要。它只需向Resolver请求一个类型为T的实例，解析器就遵从了。

了解有关解析和解析周期的更多信息。

Mocking

好吧，你可能会想。这很酷，但是前面你提到了其他的好处，比如测试和mock。那些呢？

考虑对上述代码进行以下更改：

extension Resolver {
    static func registerAllServices() {
        register { XYZViewModel(fetcher: resolve(), updater: resolve(), service: resolve()) }
        register { XYZCombinedService(resolve()) }
            .implements(XYZFetching.self)
            .implements(XYZUpdating.self)
        register { XYZService() }
        register { XYZSessionService() }

        #if DEBUG
        register { XYZMockSessionService() as XYZSessionService }
        #end
    }
}

这只是一种方法，但它说明了这个概念。现在，当MyViewController请求XYZViewModel时，它得到了一个。解析的XYZViewModel依次有其fetcher、updater和服务。

但是，如果我们处于调试模式，那么fetcher和updater现在有了一个XYZMockSessionService，它可以从嵌入的文件中提取模拟数据，而不是像平常一样发送到服务器。

而且MyViewController和XYZViewModel都不需要明白这些。

Testing

单元测试也是如此。在单元测试代码中添加如下内容。

let data = ["name":"Mike", "developer":true]
register { XYZTestSessionService(data) as XYZSessionService }
let viewModel: XYZViewModel = Resolver.resolve()

现在，您的单元和集成使用XYZTestSessionService测试XYZViewModel，它向模型提供稳定的已知数据。

再来一次。

let data = ["name":"Boss", "developer":false]
register { XYZTestSessionService(data) as XYZSessionService }
let viewModel: XYZViewModel = Resolver.resolve()

现在您可以轻松地测试不同的场景。