DTO Data Transfer Object

출처: https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html

Entity -> DTO = of()
DTO -> Entitty = toEntity()

DTO

• DB에서 데이터를 얻어 Service나 Controller 등으로 보낼 때사용하는 객체
• 로직을 갖고 잇지 않는 순수한 데이터 객체 getter/setter만 가진다
• 하지만 DB에서 꺼낸 값을 임의로 변경할필요가 없기때문에 setter가 없다
  (대신 생성자에서 값을 할당한다)
• Request와 Response용 DTO는 View를 위한 ㅡㄹ래스
• toEntity() 메서드를 이용해서 DTO에서 필요한 부분을 이용해 Entity로 만든다.

VO VS DTO

• VO는 DTO와 동일한 개념이지만 read only 속성을 가진다
• VO는 특정한 비즈니스 값을 담는 객체이고, DTO는 Layer간의 통신용도로 오고가는 객체를 말함

Entity

• 실제 DB의 테이블과 매칭될 클래스
• 가장 Core한 클래스
• @Entity, @Column, @Id 등을 이용
• 최대한 외부에서 getter 를 사용하지 않도록 필요한 로직 method를 구현한다
• 여기서 구현한 메서드는 주로 Service Layer에서 사용한다

Why divide DTO and Entity?

• View Layer와 DB Layer의 역할을 철저히 분리하기 위해
• 테이블과 매핑되는 Entity클래스가 변경되면 여러 클래스에 영향을 끼치게 되는 반면 View와 통신하는 DTO 클래스(Request/Response클래스)는 자주 변경되므로 분리해야함
• 도메인모델을 아무리 잘 설계해도 View 내에 Domain Model의 게터만 이용해서 원하는 정보를 표시하기 어려운 경우가있음, 이런 경우 Domain Model 내에 Presentation을 위한 필드나 로직을 추가하게 되는데 이러한 방식이 모델링의 순수성을 깨고 Domain model 객체를 망가뜨리게 된다
• DTO는 Domain Model을 복사한 형태로, 다양한 Presentation Logic을 추가한 정도로 사용하며 Domain Model 객체는 Persistent만을 위해서 사용한다

Controller

• 해당 요청 url에 따라 적절한 view와 mapping처리
• @Autowired Service를 통해 service의 메서드를 이용
• 적절한 ResponseEntity(DTO)를 body에 담아 Client에 반환

출처: https://gmlwjd9405.github.io/2018/12/25/difference-dao-dto-entity.html