DTO(Data Transfer Object)란 계층간 데이터 교환을 위해 사용하는 객체이다. 즉, DTO를 사용하면서 생기는 이점 = 계층 별로 객체를 나누었기 때문에 생기는 이점이다.

DTO의 이점?

  1. 요청에 대한 응답에 필요한 데이터를 모으기 위해 여러 컨트롤러를 돌며 DB를 여러번 왔다 갔다 하기 보다는 데이터베이스의 필요한 데이터를 한번에 요청한 뒤 처리하는 것을 가능하게 만들 수 있다.
  2. DTO를 적용하지 않는다면, 불필요한 데이터가 다른 계층으로 올라올 수 있다.(ex: 유저의 아이디만 필요한데 비밀번호까지 browser에 노출 되는 경우)

DTO를 코드에 적용하기 위해서 거쳐야 하는 과정

우선, dto의 범위 부터 정해야 한다.

DAO는 데이터베이스의 데이터를 클래스 인스턴스 값으로 변환해 주는 것을 말한다. CRUD의 경우 JPA에 구현되어 있기 때문에 복잡한 데이터 취합이 필요하지 않은 이상 직접 만들지 않아도 된다.

DTO를 어디까지 적용시킬지는 개인의 판단이다. 우선 본인의 경우 공부 목적이기에, 모든 계층에서 DTO를 적용시킬 예정이다.

Repositroy -> Service를 위한 DTO 작성

자바 14부터는 record로 DTo를 많이 작성한다. 또한 팩토리 메서드 패턴을 적용하기 위해 of 메서드를 만든다. 즉, 생성자가 아닌 of를 통해 객체를 생성하도록 한다.

팩토리 메서드 패턴와 record에 대한 설명은 다음을 참조. https://www.baeldung.com/java-record-keyword 위 블로그에서 처럼 record의 생성자를 커스텀하는 것 또한 가능하다. 기본적으로 public인 record의 생성자를 커스텀 할 수 있을 것으로 보인다.-> 보다 명확한 팩토리 메서드 패턴 적용 가능. https://bcp0109.tistory.com/367

from 메서드는 repostiroy의 user를 userdto로 바꾸어주는 역할을 한다. (repository -> service 를 위해 사용하는 메서드)

toEntity 메서드는 service에 있을 userdto를 user로 변환해 주는 역할을 한다. (service -> repostiroy 를 위해 사용하는 메서드)

비슷한 과정을 거쳐 게시물DTO 또한 만들었다.

Service가 Repository로 부터 DTO가져오기

위와 같이 dto를 작성했다면, dto를 사용할 수 있도록 service를 변경해야한다. 하나의 객체를 dto로 감쌀 경우, 미리 만들어둔 전역 메서드인 from을 사용하면 된다.

다음은 List 형태의 데이터를 dto로 감싸는 방법이다.

이와 같이 stream을 이용하는 방법으로 적용할 수 있다.