DTO

객체 분리

class User {
	private String name;
	private String id;
	private String pwd;
}

User 객체의 필드가 이렇다고 하자.

위 명세서와 같이 request body로 id와 pwd가 들어오면 service에서 유효성 검사를 마친 후, 비밀번호가 올바른 사용자일 경우 response body로 사용자의 id와 name을 보낸다.

POST 요청을 받을 때 User 객체로 받을 것인지 그렇다면 응답을 보낼 때는 어떻게 보낼 것인지 아니면 또다른 객체를 만들어서 반환할 것인지 고민을 해봐야 한다.

객체를 User 하나만 쓸 경우,

• 스프링 3계층(C/S/R) 간의 전송(이동) 시 데이터 변환 위험
• 클라이언트에게 굳이 전달되지 않아도 되는 데이터를 포함 → 네트워크 비용만 올라가고 보안에도 좋지 않다
• 클라이언트가 필요한 데이터 미포함 ex) 구현 코드 간 연관관계는 없지만, 화면에는 같이 뿌려져야 하는 데이터
• 단일책임 원칙
  • 데이터를 옮기는 객체가 하나일 경우 여러 계층에서 그 객체에 수정을 가하면 단일 책임 원칙이 바로 깨진다.

그렇기 때문에 데이터의 원본은 보존하고 데이터의 사본을 통해 데이터를 옮겨야 한다.

DTO vs Entity

DTO(Data Transfer Object)

• 데이터 ‘전송용’ 객체 = 엔티티(Entity)의 사본

Entity(or Domain Object)

• 데이터 원본 from DB
• DB로 들어갈/연산이 끝난 (= 원본이 될) 객체
• 엔티티는 데이터베이스의 엔티티와 다른 의미이다

Q) 엔티티는 setter를 절대 가지면 안될까요?
A) db를 업데이트를 하려면 setter가 존재할 수 밖에 없다.

DTO 변환은 어디에서?

Service?

컨트롤러에서 변환과 같은 로직을 처리하는것은 MVC 구조에 맞지 않다.

Controller?

View에 종속적인 DTO를 반환하는 것은 Service의 역할이 아니라 Controller의 역할이다. 만약 Service에서 변환을 한다면 Service가 View에 종속적이게 되어 응답의 형태 변경 시 Service도 변경되어 유지보수성이 좋지 않다.

참고한 블로그1
참고한 블로그2