const service = new UserService();
사용자가 구현체와 생성 인자를 모두 알아야 하므로 변경 영향이 커진다.
직접 생성할지 주입할지 변경 지점을 기준으로 판단한다
NestJS의 DI는 객체 생성 책임을 컨테이너로 옮겨 테스트, 교체, 수명 주기 관리를 단순하게 만듭니다.
두 방식의 차이
compareconstructor(private service: UserService) {}
필요 타입만 선언하고 실제 인스턴스는 컨테이너가 찾아 넣는다.
DI를 선택해야 하는 신호
matrix| 신호 | DI가 해결하는 것 | 결과 |
|---|---|---|
| DB나 외부 API를 테스트에서 빼고 싶다 | 대역 provider를 주입한다 | 컨트롤러와 서비스 로직만 검증한다 |
| 캐시, 저장소, 메시지 클라이언트를 바꿀 수 있다 | 토큰 또는 모듈 등록을 교체한다 | 사용하는 클래스 변경을 줄인다 |
| 인스턴스 공유 범위가 중요하다 | 컨테이너가 수명 주기를 관리한다 | 싱글톤과 요청 스코프를 일관되게 쓴다 |
기억할 기준
checkpoints값 객체처럼 의존성이 없고 변화가 적으면 직접 생성도 가능하다.
외부 자원, 정책, 테스트 대역이 필요한 객체는 provider로 둔다.
다른 모듈에서 써야 하면 exports로 공개 범위를 명확히 한다.