20. DTO
playground에서 api를 테스트해보기 위해 들어가보면 docs에서 어떤 항목을 적어야 하는지가 나와있다. 이때 작성해야할 항목을 하나하나 바로 보여주지 않고 이를테면 createinput 과같이 객체처럼 그 객체안의 내용을 작성해야 하는 경우가 있었다.
나중에 다시 보니 이는 DTO를 통해 작성한 구조였으며 DTO는 생각보다 더 많은 개념을 갖고 있었다. 그 개념과 활용에 대해서 공부해보았다.
DTO의 개념
그림에서 볼 수 있듯 DTO는 각 계층 사이사이에 존재한다. 즉 DTO란(Data Transfer Object) 데이터 전송 객체라는 이름으로 해석되며 말그대로 데이터를 담은 객체라고 이해하면 편하다. 근데 단순히 데이터를 담은 객체가 아니라 그 안에 어떤 데이터를 어떤 타입으로 적어주었는지를 담는다. 아래 내가 직접 작성한 예시를 보자.
CreateBoardInput이라는 class를 생성할 것인데 이곳에는 writer, title, contents가 각각 string 타입으로 작성되어야 한다는 것을 명시하고 있다. 얼핏 보면 Entity의 구조와 비슷하다. 따라서 DTO에는 순수하게 데이터를 저장하는 역할만 지니고 또다른 비즈니스 로직을 가져서는 안된다. 그렇다면 그냥 하나하나 필요할때마다 적게 하면 되지 뭐하러 이들을 묶어서 또다른 구조를 만들었을까? 그야 당연히 한번의 요청에 최대한 많은 데이터를 전송하기 위함이다. 백엔드에서 요청을 받고 응답을 내보내는 과정에서 데이터를 호출하는 비용을 생각해보면 납득이 간다.
Entity와 DTO의 차이
Entity는 그안에 있는 요소들의 속성(Attribute)를 갖는다. 이는 실제 DB의 테이블과 1 : 1 로 매팽되는 클래스로 DB의 테이블내에 존재하는 컬럼만을 속성값으로 가져야 한다. Entity 클래슨ㄴ 상속을 받거나 테이블내에 존재하지 않는 컬럼을 가져서는 안된다. DTO는 구조는 얼핏 유사해보이지만 기본적으로 데이터를 이동시키는 객체이기 때문에 주로 비동기 처리를 할 때 사용하며 원하는 속성만을 클래스로 가질 수 있다. 참고로 아래 참고한 사이트에서는 Entity와 DTO의 로직을 부분적으로 합치고 수정해서 좀더 깔끔하고 논리적으로 코드를 작성하는 방법도 소개되어 있는데 나는 아직 그렇게는 구현해보지 못해서 참고자료로만 남겨두고 나도 나중에 적용해봐야겠다.
https://tecoble.techcourse.co.kr/post/2020-08-31-dto-vs-entity/
요청과 응답으로 엔티티(Entity) 대신 DTO를 사용하자
…
tecoble.techcourse.co.kr