spring-boot 클론코딩을 진행하던 중에 spring data jpa를 사용하게 되었다.dto를
entity로 굳이 변환하여 db에 저장하는 이유가 궁금했고 개념정리를 해보며 이해하는 시간을 가지려 한다.
Article article = form.toEntity();//1. DTO 를 entity객체로 변환하고
Article saved = articleRepository.save(article);//2. repository에게 entity를 db안에 저장하게 함
@Entity
public class Post {
private String title;
private String content;
private String author;
}
-> post 테이블의 컬럼들을 필드로 가져야함
Domain 로직만 구현하고 Presentation 로직은 구현하지 않는다.
Entity 클래스에서 setter를 만드는 것은 피하는 것이 좋다.
Entity의 값이 변하면 Repository 클래스의 Entity Manager의 flush가 호출될 때 DB에 값이 반영되고, 이는 다른 로직들에도 영향 미친다.
View와 통신하면서 필연적으로 데이터의 변경이 많은 DTO클래스를 분리해주어야 한다.
도메인 설계가 아무리 잘 되있다 해도 Getter만을 이용해서 원하는 데이터를 표시하기 어려운 경우가 발생할 수 있는데, 이 경우에 Entity와 DTO가 분리되어 있지 않다면 Entity안에 Presentation을 위한 필드나 로직이 추가되게 되어 객체 설계를 망가뜨리게 된다. 때문에 이런 경우에는 분리한 DTO에 Presentation로직 정도를 추가해서 사용하고, Entity에는 추가하지 않아서 도메인 모델링을 깨뜨리지 않는다.
안녕하세요. 궁금한것이 있어 글 남기게되었습니다. (백엔드 개발자를 준비중인 학생입니다.)
<<DB에서 꺼낸 값을 DTO에서 임의로 조작할 필요가 없기 때문에 DTO에서는 Setter를 만들 필요가 없고 생성자에서 값을 할당한다.>>
이 부분에서 생긴 궁금증인데요, Data Access Layer와 Service Layer가 통신할 때 DTO가 중간 역할자를 하는건 맞는것 같은데... 그러면 Data Access Layer와 Service Layer에서 통신하는 DTO는 따로 생성을 한다는 말일까요? 앞의 경우가 맞다면 차라리 VO의 개념을 가져와서.. 통신을 하도록 하는게 낫지 않은가하여 질문남깁니다.
궁금했었는데 감사합니다.