使用 Python 的架构模式

第 13 章 依赖注入（和引导 依赖注入（和引导）

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在 Python 世界中，依赖注入 (DI) 被认为是可疑的。 在本书的示例代码中，没有依赖注入，我们也能应付自如！

在本章中，我们将探讨代码中导致我们考虑使用 DI 的一些痛点，并介绍如何使用 DI 的一些选项，让您来选择您认为最 Python 的方法。

我们还将在架构中添加一个新的组件，名为Bootstrap.py；它将负责依赖注入以及其他一些我们经常需要的初始化工作。 我们将解释为什么这种东西在 OO 语言中被称为组成根，以及为什么Bootstrap 脚本对我们的目的来说很好。

图 13-1展示了我们的应用程序在没有引导程序的情况下的样子：入口点进行了大量初始化工作，并传递我们的主要依赖项 UoW。

提示

如果您还没有阅读过第 3 章，那么在继续阅读本章之前，不妨先阅读一下第 3 章，尤其是关于函数式依赖管理与面向对象依赖管理的讨论。

图 13-1. 没有 Bootstrap：入口点做了很多事

提示

本章的代码位于GitHub 上的 chapter_13_dependency_injection 分支中：

git clone https://github.com/cosmicpython/code.git
cd code
git checkout chapter_13_dependency_injection
# or to code along, checkout the previous chapter:
git checkout chapter_12_cqrs

图 13-2显示我们的引导程序接管了这些职责。

图 13-2. Bootstrap 可以在一个地方解决所有问题

隐式与显式依赖关系

根据你的大脑类型，此时此刻你的脑海中可能会有一丝不安的感觉。 让我们把它说出来。我们已经向你展示了两种管理和测试依赖关系的方法。

对于数据库依赖关系，我们建立了一个谨慎的显式依赖关系框架，并提供了在测试中覆盖这些依赖关系的简便选项。我们的主处理函数声明了对 UoW 的明确依赖：

我们的处理程序明确依赖于 UoW（src/allocation/service_layer/handlers.py）

def allocate(
        cmd: commands.Allocate, uow: unit_of_work.AbstractUnitOfWork
):

这样，在我们的服务层测试中，就可以很容易地换上假冒的 UoW：

针对假冒 UoW 的服务层测试：（tests/unit/test_services.py）

    uow = FakeUnitOfWork()
    messagebus.handle([...], uow)

UoW 本身声明了对会话工厂的明确依赖：

用户工作依赖于会话工厂（src/allocation/service_layer/unit_of_work.py）

class ...