IoC와 DI

IoC는 Inversion of Control의 준말로서 제어 역전이라고도 합니다. 기존에는 어떠한 서비스를 사용하고 싶으면 아래와 같이 코드를 작성해야 했죠!

import { Controller, Get } from '@nestjs/common';
import { AppService } from './app.service';

@Controller()
export class AppController {
  // 1. 사용하고 싶은 서비스 타입 객체를 미리 선언합니다.
  private appService: AppService
  
  constructor() {
    // 2. 생성자에서 실제로 사용할 서비스 객체를 직접 생성합니다.
    this.appService = new AppService();
  }
  ...
}

지금까지는 개발자가 사용하고 싶은 객체가 있으면 이것은 개발자가 생성부터 소멸까지 직접 관리해야 했습니다. 이렇게 직접 생성하면 의존하는 서비스가 변경되면 개발자도 그에 맞추어서 코드를 수정해야 합니다.

하지만, IoC는 개발자가 사용하고 싶은 객체를 직접 생성하는 것이 아니라 객체의 생명주기 관리 자체를 외부(여기서는 Nest.js IoC 컨테이너)에 위임을 합니다! 즉, 객체의 관리를 컨테이너에 맡겨서 제어권이 넘어갔기 때문에 IoC(제어 역전)라고 하는 것입니다.

<aside> 💡 IoC는 모듈 간 결합도를 낮추기 때문에 하나의 모듈이 변경되어도 다른 모듈들에는 영향을 최소화되어 웹 어플리케이션을 지속 가능하고 확장성 있게 해줍니다!

</aside>

혹자는, 라이브러리와 프레임워크의 차이를 이렇게 말합니다. 여러분들의 의견은 어떤가요?

• 라이브러리
  • 제어권이 나에게 있다.
  • 내 코드가 필요할 때마다 내가 사용하고 싶은 라이브러리를 사용한다.
• 프레임워크
  • 제어권이 프레임워크에 있다.
  • 나의 코드를 프레임워크가 필요로 하는 경우에 프레임워크가 알아서 실행시킨다.

이렇게 제어권을 넘겨주면 개발자는 비지니스 로직을 작성하는 데 더 집중을 할 수 있습니다. 비지니스 로직을 작성하기 위해 세팅해야 하는 사전작업이 최소화되는 것이에요! 지금은 생소할 수 있어도 나중에는 없으면 불편함을 꽤 느끼실 겁니다!

DI는 이런 IoC를 수행하는 방법의 하나이며 Nest.js에서는 생성자를 통한 DI를 가장 기본적인 IoC 테크닉으로 생각하고 있습니다.

constructor(private readonly appService: AppService) {} // 얼마나 편하게요~