DTO 개념 잡기 + 공연 예매 사이트 프로젝트 - ERD 수정

오늘은

Nest.js 강의를 수강했습니다. 

그리고 프로젝트에 관하여 변경사항이 있어 ERD를 수정했습니다. 

 

DTO란 ? 

데이터 전송 객체를 의미합니다. 시스템 간 또는 계층 간에 데이터를 전달하기 위해 사용되는 객체입니다. 

데이터베이스 모델이나 비즈니스 로직 모델과는 별도로 데이터의 구조를 정의합니다. 이를 통해 데이터의 유효성 검사, 데이터 변환, 데이터 교환의 단순화 등 데이터의 무결성을 유지할 수 있게 합니다. 또한 데이터를 모아서 한번에 전달하므로 호출 횟수를 자연스럽게 낮출 수 있습니다. 

출처 : https://blog.scottlogic.com/2020/01/03/rethinking-the-java-dto.html

DTO를 사용함으로써 얻는 장점

첫 번째, Dto를 사용하면 유닛 테스트 할 때 굉장히 쉬워집니다. 
Service 레이어 에서 유닛테스트를 할 때, Entity를 그대로 사용해버리면 Service 테스트를 하게 됩니다. 이렇게 되면 DB 까지 끌어와서 테스트를 하게 되는데 굉장히 불필요하죠.
추가적으로, Entity를 Controller 같은 클라이언트단과 직접 마주하는 계층에 직접 전달하는 대신 DTO를 사용해 데이터를 교환해야 합니다. Dto는 그저 계층간 데이터 교환이 이루어 질 수 있도록 하는 객체이기 때문에, 특별한 로직을 가지지 않는 순수한 데이터 객체여야 합니다.

두 번째, 유지보수가 굉장히 쉬워집니다.
 예를 들어, User 라는 Entity에 Name, Age, Password라는 필드가 있다고 가정해 봅시다. Entity를 그대로 가져와서 하나하나 매핑을 해서 userService 로직을 짰는데 어라? User Entity 안에 hobby라는 필드가 추가가 됐습니다.
이렇게 되면 여태껏 만들어 놓은 여러 userService로직 params에 hobby를 하나하나 추가해줘야 합니다. 생각만 해도 귀찮죠...
이를 해결하기 위해 userDto를 만들었습니다. userDto 에 Name, Age, Password를 타입과 함께 넣어주고 userService 로직 params에 userDto를 넣어준 뒤, 매핑해서 사용하면됩니다. 어라? hobby필드가 추가됐어? 그렇다면 userDto에 hobby만 넣어주면 모든 userDto를 params로 갖는 userService로직에 적용이 되죠.

출처: https://resilient-923.tistory.com/356

 

 

class-validator를 사용하여 유효성 검사 DTO  

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

export class CreatePostDto {
  @IsString()
  readonly title: string;

  @IsString()
  readonly content: string;

  @IsInt()
  readonly password: number;
}

 

---

ERD 수정 

공연 테이블, 티켓 테이블과 1:N 관계를 갖는 카테고리 테이블이 추가되었습니다.

공연 테이블 안에 enum의 형태로 카테고리를 추가할 수도 있지만 테이블로 관리했을 때 

후에 카테고리 항목이 추가되거나 변경되어야 할 때 좀 더 편리하게 유지보수가 가능해집니다.