[Nest.js] Exceptionfilter, DTO, Entity, DTO와 Entity의 차이점

Exceptionfilter

문서링크

Nest에는 애플리케이션 전체에서 처리되지 않은 모든 예외를 처리하는 예외 레이어가 내장되어 있습니다

 

Throwing standard exceptions

Nest는 @nestjs/common 패키지에서 노출된 내장 HttpException 클래스를 제공합니다

일반적인 HTTP REST/GraphQL API 기반 애플리케이션의 경우 특정 오류 조건이 발생할 때 표준 HTTP 응답객체를 보내는 것이 가장 좋습니다.

Built-in HTTP exceptions

Nest는 기본 HttpException에서 상속되는 표준 예외 집합을 제공합니다. 이들은 @nestjs/common 패키지에서 노출되며 가장 일반적인 HTTP 예외중 대부분을 나타냅니다.

자세한 내용은 상단의 nest 문서링크를 참고하여 주세요

NotFoundException

    if (!movie) {
      throw new NotFoundException(`Movie with Id : ${id} not found`);
    }

---

DTO

Data Transfer Object(데이터 전송 객체)

타입등을 부여하기 위해 만들어 줘야한다

하지만 DTO를 만든 다음 타입으로 사용을 해준다고 해서 알아서 곧바로 validation까지 해주지는 않는다.

 

그렇다면 DTO는 왜 사용을 하는것일까?

 

바로 프로그래머로서 코드를 더 간결하게 만들수 있게 해주기 때문이다.

또한. NestJS가 Validation을 해줄수 있게 만들어 줄수도 있다.

 

import { IsNumber, IsString } from 'class-validator';

export class CreateMovieDto {
  @IsString()
  readonly title: string;
  @IsNumber()
  readonly year: number;
  @IsString({ each: true })
  readonly genres: string[];
}

Class-validator를 사용해주면 DTO에 validation 기능도 추가해 줄수 있다.

class-validator 문서링크

 

또한 Array의 경우 each를 사용해주면 각 요소가 string인지를 확인을 해줄수 있는 옵션도 제공을 해주고 있다.

Movie Entity

export class Movie {
  id: number;
  title: string;
  year: number;
  genres: string[];
}

Entity와 DTO차이

Entity와 DTO를 분리해서 관리해야 하는 이유는 DB Layer와 View Layer 사이의 역할을 분리 하기 위해서다.

 

Entity 클래스는 실제 테이블과 매핑되어 만일 변경되게 되면 여러 다른 클래스에 영향을 끼치고, DTO 클래스는 View와 통신하며 자주 변경되므로 분리 해주어야 한다.

 

결국 DTO는 Domain Model 객체를 그대로 두고, 복사하여 다양한 Presentation Logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용해야한다.

 

즉, Entity는 DB와 1:1매칭이 되는 Class이지만, DTO의 경우 통신간의 Data의 형태를 정의한것임으로 Entity와는 다르게 수시로 변경이 될수 있다.

 

이것을 위해서 비슷해 보이는 Entity와 DTO를 서로 분리한것이다.