DTO란
Data Transfer Object, 말 그대로 데이터를 전송하기 위한 객체이다.
왜 DTO를 사용해야 하는가
위와 같은 사용자의 정보를 저장하는 엔티티가 있다고 생각을 해보자.
우리는 해당 엔티티를 통해 DB에 사용자의 정보를 저장하게 된다.
만약 사용자들의 정보를 조회하는 요청을 왔다고 할 때, entity를 바로 전달하게 되면 password와 같은 불필요한 정보들이 노출될 수 있다.
또한 UI 계층에서 엔티티 내의 메서드를 호출하여 Model의 값이 변경될 수도 있다.
때문에 DTO 객체를 통해 필요한 데이터만 전달하고 Model을 보호 할 수 있다.
보일러 플레이트 코드
보일러 플레이트 코드는 반복적으로 재사용되는 코드를 말한다.
보통 데이터 무결성을 위해 개발을 하다 보면 getter, setter와 같은 메서드를 권장한다. [참고](https://thalals.tistory.com/279)
Lombok 어노테이션을 사용하여 쉽게 보일러플레이트를 줄일 수 있다.
Lombok은 @Data 어노테이션으로 자주 사용하는 @Getter, @Setter, @RequiredArgsConstructor, @EqualsAndHashCode @ToString 등의 집합체도 제공한다.
나도 보통 이 @Getter, @Setter 어노테이션을 사용하여 DTO를 작성하였다.
앞서 계속해서 나왔던 DTO에 레코드를 왜 적용하려는 것일까?
다시 돌아와서 롬복을 이용해서 보일러플레이트를 줄이면 되는데 레코드는 왜 나와?
일반적으로 DTO 클래스는 API 응답마다 하나씩 만드는 것을 권장한다.
롬복을 통해 할일이 줄어드는 것은 사실이지만 DTO클래스가 많아지면 그 어노테이션마저 보일러플레이트일 수 있다.
한 DTO에서는 하나의 화면만 담당해야 한다.
같은 정보를 노출하는 GET ("/order") 와 GET("/cart") 요청이 있다고 하자.당장은 두 화면 모두 같은 정보만 필요하더라도 추후에 기능이 추가되면서 응답에 변경이 일어날 수도 있기 때문이다.
Record란
JDK 14에서 등장한 레코드는 불변(immutable) 데이터 객체를 쉽게 생성할 수 있도록 하는 새로운 유형의 클래스이다.
즉, 데이터를 위한 객체라고 생각하면 좋다. (데이터를 위한 객체? Data Transfer Object와 관련이 있다는 느낌이 오면 좋겠다)
레코드 클래스를 적용한 DTO
Record를 적용한 DTO를 보면 매우매우 간단해졌다. Record의 다음과 같은 특징들 때문인데 하나씩 살펴보자.
Record 목적
공식 문서에 따르면,
- 단순한 값의 집합을 표현하는 객체 지향 구조를 고안합니다.
- 개발자가 확장 가능한 동작이 아닌 불변 데이터 모델링에 집중할 수 있도록 지원합니다.
- equals 및 접근자와 같은 데이터 기반 메서드를 자동으로 구현합니다.
- 명목상 타이핑 및 마이그레이션 호환성과 같은 오랜 Java 원칙을 유지합니다.
Record 목적이 아닌 것
- 데이터 캐리어 클래스를 선언할 때 레코드를 사용하면 간결성이 향상되기는 하지만, 'boilerplate와의 전쟁'을 선포하는 것은 목표가 아니다.
- 즉, 자바에서 반복적으로 작성해야 했던 코드(보일러 플레이트)를 줄이기 위해 도입된 것은 맞지만, 모든 보일러플레이트 코드를 대체하려는 목적은 아니다.
- "Plain Old Java 객체"의 클래스 선언을 간소화하기 위해 종종 제안되는 속성 또는 어노테이션 기반 코드 생성과 같은 기능을 추가하는 것이 목표가 아니다.
레코드 타입에 대해 알고는 있었지만 그냥 데이터 객체 그 이상 이하도 아니였다. 그러다가 DTO로 사용할 수 있다는 것을 알고 사용하게 되었는데 너무 편하다!
이번에 정리를 하면서 확실하게 정리한 개념을 토대로 정확히 알고 사용하여야겠다.
'에코노베이션 💙 > TEAM.팀쿠키' 카테고리의 다른 글
[AWS ec2, RDB, Spring Boot] 혼돈의 배포 과정 (0) | 2023.12.08 |
---|---|
v1 관리자 페이지 시나리오 (0) | 2023.07.20 |