NestJS with TypeORM：使用自定义存储库时，是否需要服务？

Question

新手问题： 使用 NestJS 和 TypeORM 时，如果创建了自定义存储库（扩展了标准存储库），是否需要单独的服务类？

目前，我只使用自定义 Repository 类，它工作正常，但我不确定这是否正确并且可能有一些副作用。

顺便说一句，在另一个项目中，我没有自定义 repo，只有一个注入两个标准 repo 的服务，这也很好。

问候，
sagerobert

Answer 1

我认为这取决于你想在 typeORM 和最“前台”代码（典型的嵌套应用程序中的控制器）之间添加多少层。

我自己解释一下：

如果您愿意，您通常可以将内置的 typeORM 存储库直接注入到您的控制器中：

import {Controller, Get} from '@nestjs/common';
import {InjectRepository} from '@nestjs/typeorm';
import {Repository} from 'typeorm';
import {User} from './entities/User.entity';

@Controller()
export class AppController {
    constructor(
        @InjectRepository(User)
        private readonly userRepository: Repository<User>,
    ) {
    }

    @Get()
    async root(): Promise<User> {
        return await this.userRepository.find(1);
    }
}

所以这将是如何检索 ID = 1 的用户的层次较少的实现。

现在，NEST 的文档建议抽象此存储库并将其注入服务而不是直接注入控制器。这使您可以减少控制器和 TypeORM 之间的绑定。相反，具有此绑定的是您的服务。如果您有许多使用此存储库的控制器，并且您决定要更改 TypeORM 并使用新奇的 ORM，则必须更改每个控制器。

现在，如果您只是将存储库注入到您的服务中并将该服务使用到您的所有控制器中，您只需更改您的服务的实现，所有控制器都将保持不变。

其次，假设您想测试您的应用程序。你将面临同样的问题。如何在没有 SQL 连接的情况下运行测试？我想您的单元测试不是为了测试 TypeORM 行为而创建的，而是为了测试您的代码行为而编写的。

模拟注入服务的存储库比模拟注入控制器的所有存储库要容易得多。

所以总结这个答案，我认为这个问题应该被关闭，因为它主要是基于意见的。但 IMO，梦想中的架构如下：

• 创建扩展 TypeORM 存储库的自定义存储库。
• 在自定义存储库中，添加使用查询生成器的方法。
• 将此自定义存储库注入您的服务中
• 将服务注入您的控制器。

永远不要在控制器中使用查询构建器，因为它很难模拟。

我希望这能回答您的问题：不需要服务类。但它会帮助您保持代码干净。