NestJS多路由公共服务依赖注入最优实现方案咨询

你当前的手动依赖注入方案不属于NestJS生态下的最佳实践，长期可维护性较差：

• 每个路由控制器都需要额外注入公共服务，再手动调用DataServiceDI传递给路由服务，冗余代码会随路由数量上涨快速膨胀
• 公共服务新增依赖时，所有关联的控制器、路由服务都需要同步修改，极易出现遗漏
• 手动实现的注入逻辑本质是重复实现NestJS原生提供的依赖注入能力，没有必要

你之前注释掉的构造函数注入方案就是NestJS官方推荐的标准实现，只需做少量调整即可实现自动注入，无需手动传递依赖：

1. 调整路由服务代码，直接通过构造函数声明依赖

@Injectable()
export class Route1Service {
    // NestJS会自动识别依赖并传入对应实例
    constructor(private FS_: FileSystemService) { }

    public GetData(): string {
        const Data:string = this.FS_.ReadLocalFile('a.txt');
        return Data;
    }
}

Route99Service等同类型路由服务都按同样规则调整即可。
2. 保持模块定义不变即可，你现有的模块配置已经满足依赖注入要求：

@Module({
    controllers: [Route1Controller],
    providers: [Route1Service, FileSystemService],
})
export class Route1Module {}

3. 简化控制器代码，无需再单独注入公共服务：

@Controller('route1')
export class Route1Controller 
constructor(
    private Route1_: Route1Service
) { }

调整后无需再手动调用DataServiceDI方法，NestJS会自动完成所有依赖的初始化和传递。

原生依赖注入完全可以保留你现有的测试优势，NestJS官方测试工具天然支持Mock替换依赖，示例代码如下：

import { Test } from '@nestjs/testing';
import { Route1Service } from './route1.service';
import { FileSystemService } from './filesystem.service';

describe('Route1Service', () => {
  let route1Service: Route1Service;
  // 自定义Mock服务
  const mockFsService = {
    ReadLocalFile: jest.fn(() => '模拟返回数据')
  };

  beforeEach(async () => {
    const moduleRef = await Test.createTestingModule({
      providers: [
        Route1Service,
        // 用Mock服务替代真实服务注入
        { provide: FileSystemService, useValue: mockFsService }
      ],
    }).compile();
    route1Service = moduleRef.get<Route1Service>(Route1Service);
  });

  it('调用GetData返回正确结果', () => {
    expect(route1Service.GetData()).toBe('模拟返回数据');
    expect(mockFsService.ReadLocalFile).toHaveBeenCalledWith('a.txt');
  });
});

Mock逻辑和你现有方案一致，不需要额外修改测试流程。

• 把FileSystemService、NoSqlService等通用公共服务封装到独立的SharedModule中并导出，所有路由模块只需导入SharedModule即可直接使用这些服务，避免每个模块重复声明Providers，也能保证公共服务是单例实例
• 可以抽象通用基础路由服务类，把重复的数据源读取逻辑封装到基类，子类只需传入文件路径、数据源配置等差异化参数，大幅减少99个路由服务的重复代码

内容的提问来源于stack exchange，提问作者Steven Scott