oshliaer

Инъекция зависимостей и создание новых сервисов

Более подробно с точки зрения архитектурных элементов NestJS, таких как провайдеры и инъекция зависимостей.

1. Инъекция зависимостей (Dependency Injection)

Инъекция зависимостей — это механизм, который позволяет компонентам (например, сервисам или контроллерам) получать необходимые им объекты (зависимости) через конструктор, вместо того чтобы создавать их самостоятельно [[5]]. Это означает, что если у вас есть BigService, который зависит от других сервисов, например PartOneService и PartTwoService, то эти зависимости будут внедрены в BigService через конструктор:

@Injectable()
export class BigService {
  constructor(
    private readonly partOneService: PartOneService,
    private readonly partTwoService: PartTwoService,
  ) {}
}

Здесь BigService не создаёт экземпляры PartOneService и PartTwoService сам, а получает их через механизм DI, что делает его более гибким и тестируемым.

2. Создание новых сервисов

Когда мы говорим о создании новых сервисов, мы имеем в виду процесс декомпозиции большого сервиса на несколько меньших, специализированных сервисов. Каждый из этих новых сервисов может быть зарегистрирован как провайдер в модуле NestJS:

@Module({
  providers: [
    BigService,
    PartOneService,
    PartTwoService,
  ],
})
export class AppModule {}

Таким образом, PartOneService и PartTwoService становятся частью системы провайдеров NestJS, и они могут быть внедрены в любой другой сервис, который от них зависит.

3. Как это связано?

Когда вы создаёте новые сервисы (например, PartOneService и PartTwoService), вы можете использовать механизм инъекции зависимостей для их внедрения в основной сервис (BigService). Таким образом, создание новых сервисов часто предполагает использование инъекции зависимостей для их интеграции, но само по себе создание сервисов не требует DI — это просто два разных аспекта организации кода.

Итог

Оба подхода дополняют друг друга, но каждый решает свою задачу. Создание новых сервисов может привести к необходимости их инъекции, но само по себе создание сервисов не является частью механизма DI.