NestJS与TypeORM:使用自定义存储库时,是否需要服务？

Question

新手问题:在使用NestJS和TypeORM时,有人创建了一个自定义存储库(扩展了标准存储库),是否需要一个单独的服务类？

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

顺便说一句,在另一个项目中,我没有自定义回购,只有一个服务可以获得两个标准回购,这也很好.

此致,
萨格罗伯特

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行为而创建的,而是为了测试您的代码行为而编写的.

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

因此,为了得出这个答案,我认为应该关闭这个问题,因为它主要是基于意见的.但恕我直言,梦想的架构如下:

• 创建扩展TypeORM存储库的自定义存储库.
• 在Custom Repository中,添加使用Query Builder的方法.
• 将此自定义存储库注入您的服务
• 将服务注入控制器.

不要将查询构建器用于控制器,因为它很难模拟.

我希望这能回答你的问题:不需要服务类.但它可以帮助您保持代码清洁.