일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 토이프로젝트
- 컨트리뷰팅
- Spring
- n poem
- GraphQL
- 함수형프로그래밍
- 2차원배열 정렬
- Npoem
- 객체비교
- SpringBoot
- resilience4j
- Not Null constraint failed
- 일급함수
- 좋은코드란
- 상속모델
- API문서화
- django
- 주니어개발자
- circuitbreaker
- 쿼리셋합치기
- DI
- bulk_create
- 운영체제
- circular dependency
- 마이크로서비스패턴
- cannot import name
- IOC
- 프로젝트설정
- Java
- bean-validator
- Today
- Total
코딩 하는 가든
SpringBoot - DTO 클래스에 대한 이해 본문
Dto 클래스에 대한 이해
현재 이동욱 님의 '스프링 부트와 AWS로 혼자 구현하는 웹 서비스'라는 책을 가지고 스프링 부트 공부를 하고 있다. 스프링 프레임워크, 사실 자바도 익숙지 않아 공부하며 흠칫하게 했던 용어들을 정리 해 보고자 한다.
DTO(Data Transfer Object)
Dto를 말 그대로 해석 하면 '데이터 전송 객체'가 된다. 즉, 데이터의 전송을 담당하는 클래스라는 소리인데, 과연 어떤 데이터를 어디에서 어디로 전송한다는 것인지 자세히 알아보자.
물론 Dto 클래스가 웹 서비스에 국한되어 사용하는 클래스는 아니지만 현재 공부하고 있는 SpringBoot framework가 주로 웹 서비스 백엔드 구축에 많이 쓰이니 그를 기준으로 정리해 보겠다.
Dto는 웹 서비스의 클라이언트와 서버, 더 자세히는 클라이언트와 서버의 서비스 계층 사이에서 교환되는 데이터를 담는 그릇이다.
서버에 다음과 같은 간단한 엔터티가 있다고 가정하자.
@Getter
@Setter
@Entity
public class Post() {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
Long id;
String title;
String content;
String author;
}
클라이언트는 위 엔터티의 데이터를 저장하기 위해 title, content, author에 대한 정보를 담아 서버에 Request를 보낼 것이다.
이 때, 서버에서 가장 먼저 일어나야 하는 일은 무엇일까.
그렇다. 데이터를 받아야 한다!(사실 따지고 보면 가장 먼저는 아니지만 직관적으로 봤을 때.) 이 때 등장하는 것이 DTO 클래스이다.
@Getter
@NoArgsConstructor
public class PostSaveRequestDto {
private String title;
private String content;
private String author;
}
DTO 클래스는 클라이언트의 Request_body에 있는 Entity의 필드들을 담아 다음 로직(저장, 수정 등...)을 처리하는 곳으로 데이터를 넘겨준다. 물론 반대로 서버 쪽에서 클라이언트 쪽으로 응답(Response)을 보낼 때도 이런 DTO 클래스를 이용하면 된다.
Django 개발을 하셨던 분이라면 Django Rest framework의 Serializer 클래스를 생각 하면 된다. 사실 본인도 'DTO클래스가 Serializer 클래스의 역할을 하는구나' 라고 뒤늦게 깨달았다..
그런데 Post 클래스와 PostSaveRequestDto 의 필드가 같은데 그럼 데이터를 Post class로 바로 받으면 되지 않을까? 라는 생각이 들 수도 있다.
이동욱님의 말을 빌리자면 'Entity 클래스는 데이터베이스와 맞닿은 핵심 클래스' 이다. 클라이언트 쪽의 변경은 빈번히 일어날 수 있는데 그에 따라 데이터 베이스의 스키마가 변경되는 것은 매우 큰 비용이라는 것이다.
사실 따져볼 것도 없이 기본적으로 Post 클래스가 Entity 클래스의 역할도 하고 데이터를 받는 일도 한다면 객체 지향의 기본 원칙인 SOLID 원칙중 SRP(Single Responsibility Principle)를 위배 한 것이 되니 당연히도 분리해야 하는 것이 맞다.
SOLID 원칙에 대해서는 다음에 자세히 다루어 보도록 하겠다.
'Spring (boot)' 카테고리의 다른 글
spring - 의존성 주입을 받는 여러 가지 방법 (0) | 2020.08.02 |
---|---|
spring - DI의 개념, 그리고 spring에서의 DI와 IoC (2) (0) | 2020.07.26 |
spring - DI의 개념, 그리고 spring에서의 DI와 IoC (1) (0) | 2020.07.22 |
Spring - 스프링 프레임워크에 컨트리뷰트를 하다. (0) | 2020.06.17 |
SpringBoot - Swagger 설정해보기 (0) | 2020.03.22 |