我不太喜欢像 nestjs 这样的大型框架；我一直喜欢以我想要的方式构建我的软件的自由，以及我以轻量级方式决定的结构。但在测试 nestjs 时我喜欢的是依赖注入。
依赖注入（di）是一种设计模式，它允许我们通过消除创建和管理类依赖关系的责任来开发松散耦合的代码。这种模式对于编写可维护、可测试和可扩展的应用程序至关重要。在 typescript 生态系统中，tsyringe 作为一个强大且轻量级的依赖注入容器脱颖而出，它简化了这个过程。
tsyringe 是一个用于 typescript/javascript 应用程序的轻量级依赖注入容器。由 microsoft 在其 github (https://github.com/microsoft/tsyringe) 上维护，它使用装饰器进行构造函数注入。然后，它使用控制反转容器来存储基于令牌的依赖项，您可以用该令牌交换实例或值。
在深入了解 tsyringe 之前，我们先简要探讨一下什么是依赖注入以及它为何如此重要。
依赖注入是一种技术，对象从外部源接收其依赖项，而不是自己创建它们。这种方法有几个好处：
首先，让我们在您的 typescript 项目中设置 tsyringe：
npm install tsyringe reflect-metadata
在 tsconfig.json 中，确保有以下选项：
{
"compileroptions": {
"experimentaldecorators": true,
"emitdecoratormetadata": true
}
}
在应用程序的入口点导入反射元数据：
import "reflect-metadata";
应用程序的入口点例如是 next.js 13+ 上的根布局，也可以是小型 express 应用程序中的主文件。
我们以介绍中的示例为例，添加 tsyringe 糖：
让我们从适配器开始。
// @/adapters/useradapter.ts
import { injectable } from "tsyringe"
@injectable()
class useradapter {
constructor(...) {...}
async fetchbyuuid(uuid) {...}
}
注意到 @injectable() 装饰器了吗？是告诉tsyringe这个类可以在运行时注入。
所以我的服务正在使用我们刚刚创建的适配器。让我们将该适配器注入到我的服务中。
// @/core/user/user.service.ts
import { injectable, inject } from "tsyringe"
...
@injectable()
class userservice {
constructor(@inject('useradapter') private readonly useradapter: useradapter) {}
async fetchbyuuid(uuid: string) {
...
const { data, error } = await this.useradapter.fetchbyuuid(uuid);
...
}
}
这里我还使用了 @injectable 装饰器，因为 service 将被注入到我的命令类中，但我还在构造函数参数中添加了 @inject 装饰器。此装饰器告诉 tsyringe 在运行时为 useradapter 属性提供令牌 useradapter 的实例或值。
最后但并非最不重要的一点是，我的核心的根源：命令类（通常被错误地称为用例）。
// @/core/user/user.commands.ts
import { inject } from "tsyringe"
...
@injectable()
class usercommands {
constructor(@inject('userservice') private readonly userservice: userservice) {}
async fetchbyuuid(uuid) {
...
const { data, error } = this.userservice.fetchbyuuid(uuid);
...
}
}
此时，我们已经告诉 tsyringe 将要注入什么以及要在构造函数中注入什么。但我们还没有制作容器来存储依赖项。我们可以通过两种方式做到这一点：
我们可以使用依赖注入注册表创建一个文件：
// @/core/user/user.dependencies.ts
import { container } from "tsyringe"
...
container.register("userservice", {useclass: userservice}) // associate the userservice with the token "userservice"
container.register("useradapter", {useclass: useradapter}) // associate the useradapter with the token "useradapter"
export { container }
但是我们也可以使用@registry装饰器。
// @/core/user/user.commands.ts
import { inject, registry, injectable } from "tsyringe"
...
@injectable()
@registry([
{
token: 'userservice',
useclass: userservice
},
{
token: 'useradapter',
useclass: useradapter
},
])
export class usercommands {
constructor(@inject('userservice') private readonly userservice: userservice) {}
async fetchbyuuid(uuid) {
...
const { data, error } = this.userservice.fetchbyuuid(uuid);
...
}
}
container.register("usercommands", { useclass: usercommands})
export { container }
两种方法各有利弊，但归根结底，这只是个人喜好的问题。
现在我们的容器已经充满了我们的依赖项，我们可以根据需要使用容器的resolve方法从容器中获取它们。
import { container, usercommands } from "@/core/user/user.commands"
...
const usercommands = container.resolve<usercommands>("usercommands")
await usercommands.fetchbyuuid(uuid)
...
</usercommands>
这个例子非常简单，因为每个类只依赖于另一个类，但我们的服务可能依赖于许多类，依赖注入确实有助于保持一切整洁。
但是等等！别就这样离开我！测试怎么样？
我们的注入还可以通过将模拟对象直接发送到我们的依赖项中来帮助我们测试代码。让我们看一个代码示例：
import { container, usercommands } from "@/core/user/user.commands"
describe("test ftw", () => {
let useradaptermock: useradaptermock
let usercommands: usercommands
beforeeach(() => {
useradaptermock = new useradapter()
container.registerinstance<useradapter>("useradapter", useradapter)
usercommands = container.resolve<usercommands>("usercommands")
});
...
});
</usercommands></useradapter>
现在 useradapter 令牌包含一个模拟，它将被注入到依赖类中。
使用标记进行命名：不要使用字符串文字作为注入标记，而是创建常量标记：
export const USER_REPOSITORY_TOKEN = Symbol("UserRepository");
作用域容器：将作用域容器用于 web 应用程序中的请求作用域依赖项。
不要过度使用 di：并不是所有东西都需要注入。使用 di 来实现横切关注点和可配置的依赖关系。
如果你已经读到这里，我想说谢谢你的阅读。我希望这篇文章对您有所启发。请记住在实现依赖注入和架构模式时始终考虑项目的特定需求。
点赞和评论反馈是最好的改进方式。
编码愉快！