프로젝트를 진행하며 도메인 별로 DTO, DAO, Entity를 구분하는데 정확히 개념을 짚고 넘어가야할 것 같아서 정리해본다.
특히 왜 이렇게 구분해서 사용해야하는지를 집중적으로 공부한 내용에 대해 적어보겠다.
💻 Entity / DTO / DAO 란?
🌀 Entity
: 데이터베이스에 저장되는 데이터 객체로 데이터베이스에 직접적으로 연결된다. DB 테이블에 존재하는 컬럼들을 필드로 가지고 있다.
@Entity
public class User {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
@Column(name = "id", nullable = false)
private Long id;
private String nickName;
private String introduce;
private String profileImg;예를 들어 User 라는 테이블에 id, nickName, introduce, profileImg라는 컬럼을 가지고 있다면 해당 Entity 클래스는 위와 같이 작성되게된다.
JPA에서는 @Entity 어노테이션을 붙여주면 해당 클래스가 Entity임을 인지하게된다.
추가로 Entity 클래스에서는 Setter를 만드는 것을 지양하고 도메인 로직이 필요하다면 이를 포함한다. 또, 일반적으로 필요한 값만 사용할 수 있는 @Builder 패턴을 사용한다.
🌀 DTO (=Data Transfer Object)
: 계층 간 데이터 교환 역할을 담당하여 Entity를 가지고 만드는 일종의 Wrapper 역할로 기능한다. Entity로 직접 데이터에 접근하지 않고 Dto를 통해서 접근하도록 한다.
그렇기 때문에 Dto는 다른 특별한 로직 없이 이루어진 순수한 데이터 객체이다.
@Getter
@NoArgsConstructor(access = lombok.AccessLevel.PROTECTED)
@AllArgsConstructor(access = lombok.AccessLevel.PROTECTED)
public class UserUpdateRequest {
private String nickName;
private String introduce;
private String profileImg;
}추가로 DTO 클래스에서 toEntity(), toDto() 같은 메서드로 Presentation 로직을 구현하여 사용하곤한다.
🌀 DAO (=Data Access Object)
: 실제 데이터베이스에 접근하는 객체로 JPA에서 데이터베이스에 데이터를 'CRUD'하는 레포지토리 객체들이 Dao로써 기능한다.
💻 왜 Entity와 DTO를 구분해야할까?
우선 요청과 응답 처리를 담당하는 Controller(API)에서 데이터를 DTO의 형태로 받아서 Service(Application)에 전달한다. 그럼 Service에서 DTO를 Entity로 변환하고 로직을 수행한 후에 Repository로 전달한다. 이렇게 Entity를 받은 Repository가 데이터베이스와의 인터페이스 역할을 하여 결론적으로 데이터를 전달한다.
🌀 Entity를 직접 반환하게 되었을 때의 단점
1. 유지보수
요구사항이 변경된 경우 API 스펙이 변경되는 일이 생기면 코드 수정이 불가피하기에 효과적인 유지보수를 위해 DTO를 사용한다.
2. 데이터의 효율적인 전송
Entity를 직접 반환하는 경우 안에 존재하는 모든 데이터가 반환되기 때문에 필요없는 데이터도 전달될 수 있다.
3. 책임 분리
유지보수와도 비슷한 맥락의 이야기인데 Entity의 값이 변하게 되면 flush가 호출될 때 데이터베이스에 반영이 되며 다른 로직에도 영향을 끼치게 된다. 그렇기 때문에 데이터의 변경과 수정이 많이 일어나는 DTO 클래스를 분리해줌으로써 책임을 나눠줄 수 있다.
사실 아직까지도 dto를 어느 단위로 구분해야 할지 등 어렵고 헷갈리는 부분이 많지만 개념을 정리해나가며 차차 공부하면서 익혀야겠다..😓
