[NestJS] Provider, IOC, DI

😑 Provider

- NestJS의 기본 개념.

- 의존성을 주입 시킨다 

- service, repository, factory, helper 

 

객체가 서로 다양한 관계를 만들 수 있다는 것을 의미.

객체의 인스턴스를 연결해주는 기능은 Nest 런타임 시스템에 위임될 수 있음 (?)

 

 

 

😑 Nest 런타임 시스템 

 

: NestJS 내부에서 작동하는 시스템으로, Provider 클래스의 인스턴스를 생성하고 관리하는 역할을 한다.

개발자는 명시적으로 Provider를 정의하고 설정하지만,이러한 Provider 인스턴스의 생성과 관계는 NestJS

런타임 시스템에 의해 자동으로 처리된다. 이것은 개발자가 객체 생성과 의존성 관리에 대해 신경 쓰지 않고도

NestJS 애플리케이션을 효율적으로 작성할 수 있게 해준다.

 

@Injectable()

: NestJS 런타임은 해당 클래스를 식별하고 관리한다.

 

객체의 인스턴스 연결

: NestJS는 Provider클래스의 인스턴스를 생성하고 서로 연결하여 의존성을 관리한다.

이것은 의존성 주입 컨테이너를 사용하여 이루어진다.

 

A가 서비스 B에 의존한다면, NestJS는 서비스 A의 인스턴스를 생성하면서 필요한 서비스 B의

인스턴스도 필요한 경우에 함께 생성하고 서로 연결한다.

 

 

 

😑 계층형 구조(Layered Architecture)

 

1. 계층형 구조 Layered Architecture

- 각 구성요소들의 관심사의 분리(Seperation of Concerns).

 

- Presentation layer: 클라이언트와 통신.

- Business layer: 비지니스 로직

- Persistence layer: DAO Data Access Object, DB 접근

- Database layer: DB

 

2. 다층 구조 n-tier Architecture

- 비지니스 로직을 분리

 

- 2 Tier : 클라이언트 - DB서버

- 3 Tier: DB서버 - 클라이언트 - 미들웨어 

 

 

Controller -> Presentation layer

Service -> Business layer, Persistence layer

 

NestJS에서의 Provider의 명칭은 계층형 구조에서 Business layer, Persistence layer를 의미.

 

(응집도를 높이고 결합도를 낮춤 -> 재사용, 유지보수성 효율 높아짐)

 

 

 

😑 제어 역전(IoC, Inversion of Control) 

😑 의존성 주입(Dependency Injection)

 

: 프로그램의 제어 흐름을 개발자가 아닌 외부 요소(=Nest 런타임 시스템) 에게 위임하는 개념

 

일반적으로 프로그램은 개발자가 제어하는 방식으로 동작한다. 

(즉, 개발자가 코드의 흐름과 제어를 결정) 

 

어떤 작업을 수행할 때 개발자가 직접 호출하지 않고, 

외부에서 이를 제어하도록 만든다.

 

NestJS 프레임워크 자체가 애플리케이션의 흐름을 관리하고,

개발자는 프레임워크에서 어떤 서비스가 필요한지를 알려주고

요청한다.

 

NestJS 프레임워크가 그 서비스를 찾아서 제공하고 

필요한 시점에 호출한다. 

 

이로써 개발자는 애플리케이션의 전반적인 제어 흐름을 개발하는데

집중이 가능해진다.

 

// UserService.ts - 서비스 클래스
import { Injectable } from '@nestjs/common';

@Injectable() 
// 1. @Injectable(), NestJS는 이 클래스가 서비스임을 인지
// (의존성 주입을 받을 수 있는 클래스임을 의미)
export class UserService {
  getUsers(): string[] {
    return ['User1', 'User2', 'User3'];
  }
}

// UserController.ts - 컨트롤러 클래스
import { Controller, Get } from '@nestjs/common';
import { UserService } from './UserService';
// 2. DI - 의존성 주입, 
// 개발자가 UserService의 인스턴스를 생성,관리 하지 않음
// NestJS 프레임워크가 UserController에 필요한 UserService 인스턴스 제공

@Controller('users')
export class UserController {
  constructor(private readonly userService: UserService) {}

  @Get()
  getUsers(): string[] {
    return this.userService.getUsers();
  }
}

IOC 컨테이너가 적절한 UserService 인스턴스를 제공하므로 코드는 
더 모듈화 되고 유지보수가 쉬워짐

 

 

😑 readonly

: Typescript 에서 멤버 변수를 읽기 전용으로 만드는 특성을 가지고 있음

 

생성자 파라미터에 readonly를 사용하면 

해당 필드는 한 번 설정되면 변경할 수 없게 된다.

 

불변성 Immutability 보장

readonly를 사용하면 필드가 한 번 설정되면 

후속 코드에서 변경할 수 없으므로 불변성을 보장

(예측 가능한 코드와 버그를 줄이는 데 도움)

 

컴파일러 에러 감지

readonly를 사용한 필드를 변경하려는 시도를 감지하고

에러를 발생시킴

 

가독성 향상

언제 어디서 설정되는지 코드에서 명확히 파악 가능

 

 

컴파일러 에러 감지, 가독성 향상 시도를 감지 (?)

Typescript 컴파일러는 코드를 컴파일할 때 타입 검사(Type Checking) 을 수행한다.

이것은 코드의 타입 안정성을 유지하고 오류를 사전에 감지하는 중요한 역할을 한다.

 

readonly 키워드를 사용한 필드는 수정이 허용되지 않으므로, 

TypeScript 컴파일러는 해당 필드를 변경하려는 코드를 발견하면 

컴파일 오류를 생성하여 개발자에게 알려준다.

 

 

😑 참고 

 

https://www.wisewiredbooks.com/nestjs/overview/04-provider.html

프로바이더 - 쉽게 풀어 쓴 Nest.js

 

https://m.blog.naver.com/fbfbf1/222620699725

[NestJS] IoC, DI, Singleton