[Nest.js 공식문서 읽기] Provider

Provider

provider는 nest의 기본개념이다.

nest의 services, repositories, factories, helpers등 기본 클래스들은 대부분 provider로 취급될 수 있다.

그리고 provider는 종속성으로 주입될 수 있다.

이것의 의미는 객체들이 다양한 관계를 만들 수 있다는 것을 의미하고, 그 관계 설정에 맞게 인스턴스를 생성하는 일은 nest 런타임에게 위임된다.

물론 provider도 controller처럼 module에 메타데이터를 전달해주어야 nest가 해당 클래스를 provider로 인식할 수 있다.

 

📌 SOLID(객체 지향 설계)
nest로 객체 지향 방식의 종속성을 설계하고 구상할 수 있기 때문에 SOLID 원칙을 따르는 것을 강력히 권고한다.
The SOLID ideas are

- 단일 책임원칙(SRP) : 한 클래스는 하나의 책임만 가져야 한다.The Single-responsibility principle: "There should never be more than one reason for a class to change." In other words, every class should have only one responsibility.

- 개방-폐쇄 원칙(OCP) : 소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.The Open–closed principle: "Software entities ... should be open for extension, but closed for modification."

- 리스코프 치환 원칙(LSP): 프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.The Liskov substitution principle: "Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it." See also design by contract.인터페이스 분리 원칙(ISP) : 특정 클라이언트를 위한 인터페이스 여러개가 범용 인터페이스 하나보다 낫다.The Interface segregation principle: "Clients should not be forced to depend upon interfaces that they do not use."

- 의존관계 역전 원칙(DIP) : 프로그래머는 추상화에 의존해야지, 구체화에 의존하면 안된다. 의존성 주입은 이 원칙을 따르는 방법 중 하나다.The Dependency inversion principle: "Depend upon abstractions, [not] concretions."

- 참고 : 위키백과(https://ko.wikipedia.org/wiki/SOLID_(객체_지향_설계))

 

의존성 주입(dependency injecton)

• 소프트웨어 엔지니어링에서 의존성 주입(dependency injection)은 하나의 객체가 다른 객체의 의존성을 제공하는 테크닉이다. "의존성"은 예를 들어 서비스로 사용할 수 있는 객체이다. 클라이언트가 어떤 서비스를 사용할 것인지 지정하는 대신, 클라이언트에게 무슨 서비스를 사용할 것인지를 말해주는 것이다. "주입"은 의존성(서비스)을 사용하려는 객체(클라이언트)로 전달하는 것을 의미한다. 서비스는 클라이언트 상태의 일부이다. 클라이언트가 서비스를 구축하거나 찾는 것을 허용하는 대신 클라이언트에게 서비스를 전달하는 것이 패턴의 기본 요건이다.
• 참고 : 위키백과(https://ko.wikipedia.org/wiki/의존성_주입)
• Nest에서 종속성을 주입하는 방법은 종속성을 종속성을 사용하려는 객체로 전달하는 것이다. 즉, 종속성을 사용하려는 레이어로 import 하고, 생성자(constructor)를 활용하여 의존성을 부여(DI)하는 것으로 느슨한 결합을 사용할 수 있다.
• Nest에서는 TypeScript 기능 덕분에 종속성이 유형별로 해결되므로 매우 쉽게 관리할 수 있습니다. 아래 예제에서 Nest는 BoardRepository 인스턴스를 만들고 반환함으로써 boardRepository를 resolve합니다(일반적으로 싱글톤의 경우 이미 요청된 경우 기존 인스턴스를 반환함). 이 종속성이 resolve되어 서비스의 생성자(또는 표시된 속성에 할당됨)로 전달됩니다

📌 What’s mean “resolve” in Nest.js?
The main meaning of resolve in software development is to find the solution or answer of a problem or to find and load a specific module or dependency at runtime, but it could have other meanings depending on the context and the specific implementation of the technology.

- 참고 : chatGPT

 

Service

서비스 클래스는 @injectable() 데코레이터로 감싸져서 모듈에 제공되며 이 서비스 인스턴스가 모듈의 프로바이더로 등록되면 애플리케이션 전체에서 사용될 수 있다. @Injectable() 데코레이터가 해당 클래스를 Nest IoC 컨테이너에서 관리할 수 있는 클래스임을 선언하는 메타데이터를 첨부하기 때문이다.

• IoC(제어의 역전)을 Nest에서는 providers에 클래스를 넣는 것으로 사용할 수 있다.
  • 싱글톤 패턴의 제일 큰 문제는 강한 결합이였다. 하지만 이것을 해결하기 위하여 Nest가 IoC를 지원한다.
  • Nest가 bootstrap을 할 때 Module에 등록된 의존성들을 검사하여 프로바이더 인스턴스를 생성한다.
  • 이것이 애플리케이션 전역에 단일 인스턴스로 공유가 되서 빠른 속도로 처리가 가능하다.

📌 싱글톤 패턴
소프트웨어 디자인 패턴에서 싱글턴 패턴(Singleton pattern)을 따르는 클래스는, 생성자가 여러 차례 호출되더라도 실제로 생성되는 객체는 하나이고 최초 생성 이후에 호출된 생성자는 최초의 생성자가 생성한 객체를 리턴한다. 이와 같은 디자인 유형을 싱글턴 패턴이라고 한다. 주로 공통된 객체를 여러개 생성해서 사용하는 DBCP(DataBase Connection Pool)와 같은 상황에서 많이 사용된다.

- 출처 : 위키백과

📌 제어의 역전(IoC)
제어 반전, 제어의 반전, 역제어는 프로그래머가 작성한 프로그램이 재사용 라이브러리의 흐름 제어 를 받게 되는 소프트웨어 디자인 패턴을 말한다. 줄여서 IoC(Inversion of Control)이라고 부른다.

- 출처 : 위키백과

import { Injectable } from '@nestjs/common';
import { Board } from './board.entity';
import { BoardRepository } from './board.repository';
import { InjectRepository } from '@nestjs/typeorm';

@Injectable()
export class BoardsService {
  constructor(
    @InjectRepository(BoardRepository)
    private readonly boardRepository: BoardRepository,
  ) {}

  async getAllBoards(): Promise<Board[]> {
    return await this.boardRepository.find();
  }
}

서비스는 컨트롤러에서 데이터의 유효성 체크를 하거나 데이터 베이스에 아이템을 생성하는 등의 작업을 하는 부분을 처리한다. → 즉, 원래 컨트롤러에서 하던 걸 서비스에서 하게 한다.

주로 db관련 로직을 처리한다. db에서 데이터를 가져오거나 db안에 게시판 생성할 때 생성한 게시판 정보를 넣어주는 등의 로직을 처리한다.