Providers
•
프로바이더는 네스트의 기본적인 컨셉이다.
•
많은 기본 네스트 클레스들이 프로바이더(서비스, 레포지토리, 팩토리, 헬퍼 등등) 로 취급된다.
•
프로바이더의 기본 아이디어는 그것이 의존성을 주입할 수 있다는 것이다.
•
이것은 오브젝트들이 서로 다양한 관계를 만들수 있음을 의미한다.
•
그리고 instances of Objects "wiring up" 기능은 네스트의 런타임 시스템에 largely be delegated 될 수 있습니다.
•
이전 쳅터에서느 우리는 간단한 CatsController를 만들었습니다.
•
컨트롤러는 HTTP request를 처리해야 하며, 더 복잡한 일은 provider 에게 위임해야 합니다.
•
프로바이더는 plain JS class 이며 module에 providers 로 선언되어 있습니다. (declared as providers in module)
HINT : 네스트를 사용하면 보다 OO-way(OOP 와 비슷한 의미) 로 종속성을 설계하고 디자인 할 수 있으므로 SOLID 원칙을 따르는 것이 좋습니다.
Dependency Injection
•
네스트에서, 타입스크립트 덕분에, 매우 쉽게 디펜던시를 매니지 할 수 있게 되었습니다. (그것이 단지 타입으로 resolved 되기 때문에)
•
아래 예 처럼, 네스트는 catService 를 생성하고, 그 인스턴스를 리턴하여 resolve 할 것입니다.
•
(아니면, 평소 싱글톤 케이스처럼, 이미 만들어진 인스턴스를 리턴 할 것입니다.)
•
This dependency is resolved and passed to your controller's constructor (또는 표시된 속성에 할당됨)
constructor(private catsService: CatsService) {}
Plain Text
복사
Scopes
•
제공자는 기본적으로 어플리케이션 라이프사이클과 동기화된 lifetime ("scope") 를 가지고 있습니다.
•
어플리케이션이 부트스트랩 될 때, 모든 디펜던시가 해결됩니다. (그러므로 모든 제공자가 인스턴스와 됩니다.)
•
마찬가지로, 어플리케이션이 셧다운 될 때, 모든 프로바이더들이 디스트로이드 됩니다.
•
그러나 당신은 당신의 프로바이더의 lifetime 이 request-scoped 인 상태로 만들수 있습니다.
•
여기에서 그 기술을 배워보세요 여기
Custom Providers
•
네스트는 기본적으로 빌트인 Inversion of Control ("IoC") 컨테이너를 가지고 있습니다. (프로바이더 간에 관계를 해결하는)
•
이 기능은 위에서 설명한 종속성 주입 기능의 기초가 됩니다.
•
또한 지금까지 설명한 것보다 훨씬 파워풀 합니다.
•
프로바이더를 디파인 하는 여러 방법들이 있습니다 : plain values, classes, and either asynchronous or synchronou factories.
•
더 많은 것을 배워보세요 여기
Optional providers
•
Occasionally(때때로), 반드시 해결되지 않아도 되는 종속성이 있을수 있습니다. (이딴게 왜있는거야 ..?)
•
예를들어, 당신의 클레스는 configuration object에 종속되어있을 수 있습니다.
•
하지만, if none is passed(none 이 통과되면?), 디폴트 벨류가 사용됩니다.
•
이러한 경우에, 디펜던시는 옵셔널이 됩니다. (configuration provider 의 결핍이 에러를 이끌지 않기 때문입니다.)
•
프로바이더가 옵셔널이라는 것을 알리려면, constructor's signature 에서, @Optional() 데코레이터를 사용하세요.
import { Injectable, Optional, Inject } from '@nestjs/common';
@Injectable()
export class HttpService<T> {
constructor(@Optional() @Inject('HTTP_OPTIONS') private httpClient: T) {}
}
Plain Text
복사
•
우리가 HTTP_OPTIONS 라는 커스텀 토큰을 사용하기 때문에, 위 예는 커스텀 프로바이더를 사용하는 것이다.
•
이전 예는 클래스를 통한 종속성을 나타내는 constructor-based injection 을 보여주었습니다.
•
더 많은 정보는 여기
Property-based Injection
•
이전 기술에는 우리는 프로바이더가 생성자메소드를 통해 주입되는 constructor-based injection 을 사용했다.
•
아주 특별한 케이스에서, property-based injection 이 might be useful 하다.
•
예를 들어 최상위 클래스가 하나 또는 다수의 프로바이더들에게 의존성을 가지고 있다면, 이러한 경우 하위 클레스에서 super를 통해 넘겨주는 것은 그렇게 좋은 방법이 아니다.
•
이러한 경우를 피하기 위해 @Inject() 데코레이터를 프로퍼티에게도 사용 할 수 있다.
import { Injectable, Inject } from '@nestjs/common';
@Injectable()
export class HttpService<T> {
@Inject('HTTP_OPTIONS')
private readonly httpClient: T;
}
Plain Text
복사
WARNING : 만약 당신의 클레스가 아무 프로바이더를 상속받고 있지 않다면, 너는 항상 constructor-based injection 을 사용하는것이 좋다.
Provider registration
•
이제 우리는 CatsService 라는 프로바이더를 디파인하였다.
•
그리고 CatsController 라는 위에서 만든 서비스의 소비자가 있다.
•
우리는 네스트가 injection 을 수행하도록 서비스를 등록해줄 필요가 있다.
•
우리는 app.module.ts 파일을 열고, @Module 데코레이터의 providers 배열에 서비스를 넣어준다.
import { Module } from '@nestjs/common';
import { CatsController } from './cats/cats.controller';
import { CatsService } from './cats/cats.service';
@Module({
controllers: [CatsController],
providers: [CatsService],
})
export class AppModule {}
Plain Text
복사
•
네스트는 이제 CatsController 클레스의 의존성을 해결 할 수 있다.
Manual instantiation (수동 인스턴스화)
•
Thus far(지금까지), we've discussed how Nest automatically handles most of details of resolving dependencies
•
In certain circumstances (특정 상황에서), 빌트인 DI 에서 벗어나, 수동으로 프로바이더를 찾아내고 인스턴스화 하는 것은 아래 두 토픽에서 간단히 살펴볼 것이다.
•
•
