[SpringBoot] DTO, DAO, VO 개념 알아보기

이번에 만들 프로젝트에서 SpringBoot를 MVC 패턴으로 설계하기로 했다!

MVC를 기반으로 한 프로젝트 구조를 설계해보자.

그 전에 먼저 알아야할 개념들이 있다.

 

MVC패턴 알아보기

 

 

 

DAO(Data Access Object)

• 데이터 베이스에 접근하기 위한 객체
• DB에 접근하기 위한 로직과 비즈니스 로직을 분리하기 위해서 사용

 

DTO(Data Transfer Object)

• 계층 간 데이터 교환을 하기 위해 사용하는 객체
• 즉, 데이터를 이동(Transfer)하기 위한 객체
• DTO는 로직을 가지지 않는 순수한 데이터 객체(getter & setter 만 가진 클래스) 이다.

Q : 데이터를 움직일 때 왜 Entity 객체를 그대로 사용하지 않고 굳이 DTO를 사용하는 것인가?

A: 관심사의 분리(Separation of Concerns, SoC)

1. 객체를 표현하기 위한 계층(View Layer)와 저장하는 계층(DB Layer)의 역할을 분리하기 위함
- Entity는 모델의 비밀번호 같이 View에서는 노출하면 안되는 민감한 정보를 가지고 있음 -> View에 전달X

2. Entity 객체의 무결성
- Entity 객체를 그대로 사용하면 프로그래머의 의도와 다르게 데이터가 변질 될 수 있음

3. View와 통신하는 DTO는 자주 변경됨
- View와 통신하는 RequestDTO, ResponseDTO는 요구사항에 따라 자주 변경된다. 

4. 도메인 모델링을 지키기 위하여
- 도메인 설계를 잘하였다고 하더라도, 원하는 데이터만 표시하기가 쉽지 않다.
- Entity에 표현을 위한 필드나 로직이 추가되면 객체 설계를 망가뜨릴 수 있다.
- 따라서 DTO에 표현을 위한 로직을 추가해서 사용하는 것이 Entity의 도메인 모델링을 지킬 수 있다.

 

 

VO(Value Object)

• 값 오브젝트로써 값을 위해 쓰임
• read-only 특징(사용하는 도중에 변경 불가능, 오직 읽기만 가능)을 가진다.
• DTO와 유사하지만 VO는 getter만 가진 클래스

 

Entity

• 도메인 모델이라고 불림
• DB 테이블에 존재하는 Column들을 필드로 가지는 객체
• Entity는 DB 테이블과 1대1 대응이며, 테이블에 가지지 않는 Column을 필드로 가져서는 안 된다.
• 다른 클래스를 상속받거나 인터페이스의 구현체여서는 안되고, 순수한 데이터 객체인 것이 좋다.
• (중복되는 내용이 있을 경우, baseEntity를 만들어 상속 가능)

 

예를 들어 DB의 '회원'이라는 테이블이 있다고 가정하자.

'회원' 테이블에 컬럼이 customer_id, customer_password가 있다고 가정한다면,

 

@Entity
public class Customer{

    @Id
    private Long customer_id;

    private String customer_password;

}

 

회원 테이블에 대응하는 Entity 클래스 Customer는 위와 같은 필드들만 가져야 한다.

 

 

 

틀린 부분이 있으면 지적해주시면 감사하겠습니다.

---

Reference

DAO, DTO, Entity 참고

DTO 사용 이유