디자인 패턴

의존성 주입

DI; Dependency Injection.

really just a pretentious way to say 'taking an argument'¹

• 내가 쓸 인터페이스부터 정의하고 (의존성), 나중에 구현체 끼어넣기 (주입).
• 구현체만 바꾸면 동작이 그대로라 좋다.

예시

class UserService {
  constructor(
    // userRepository는 여기서 의존성 주입한다.
    // 인스턴스 생성은 프레임워크에 맡긴다. (= IoC)
    @InjectRepository(User)
    private readonly userRepository: Repository<User>,
  ) {}

  async create(body: BodyDto): Promise<ResponseDto> {
    // this.userRepository로 열심히 작업한다.
    // 나중에 Repository 종류가 바뀌면 (RDB에서 documented DB로 바뀐다던가) 인터페이스가 동일한 한 Repository만 새로 구현해서 DI하면 된다.
  }
}

의문

• UserController는 어차피 UserService에 의존하는데 (그렇게 설계했으니까) 이것마저 DI할 필요가 있을까?
• 모든 것들을 이것저것 DI하는데, 주입하는 대상을 바꾸었을 때 인터페이스가 바뀌는 상황이면 DI를 할 필요가 있을까?

참고

• Taehee Kim, 프런트엔드에서 의존성을 제어하는 법.
• Mark Seemann, Dependency injection is passing an argument.
• Jin-Wook Chung, DI는 IoC를 사용하지 않아도 된다.
• Rúnar Bjarnason, Dead-Simple Dependency Injection.