本文为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()
现在您可以轻松地测试不同的场景。