DAO, DTO, VO, Entity

 

Spring Framework나 MVC 패턴을 사용하게 되면 만나게 되는 "데이터 교환 및 전송"에서 사용하는 개념들을 알아볼게요!

 

 

재밌겠죠? (일단 전 아니요)

 

 

Preview

개념	역할	주요 특징	사용 목적
VO	불변 객체	값을 변경할 수 없음, 동등성 비교	데이터의 무결성 보장, 동일한 값 객체 재사용
DAO	데이터베이스 접근	DB와 직접 연결, CRUD 수행	DB와 비즈니스 로직을 분리
DTO	데이터 전달	값 변경 가능, 직렬화 가능	네트워크 성능 최적화, 데이터 보호

 

 

DAO(Data Access Object)

데이터베이스와의 직접적인 상호작용을 담당하는 객체

 

• 특징

- 데이터를 CURD(Create, Read, Update, Delete)하는 역할을 수행하며, DB와의 결합도를 낮추고 유지보수성을 향상시킴
- DB 연결 및 쿼리 실행 역할을 함
- 비즈니스 로직과 DB접근 로직을 분리함
- 인터페이스 기반으로 설계 가능하여 다양한 DB 구현체를 변경할 수 있음
- JDBC, JPA, MyBatis등 다양한 방식으로 구현 가능

 

• 장점
  • DB 변경 시, 비즈니스 로직 영향을 최소화 → 유지보수 용이
  • 데이터 접근 로직을 캡슐화하여 코드 재사용성이 높음
  • 보안 강화 → SQL Injection 방지 등의 기법 적용 가능
• 단점
  • DAO 계층을 추가하면 복잡성이 증가할 수 있음
  • 잘못 설계 시, 성능 저하 → 불필요한 DB호출 증가 가능
  • SQL과 ORM을 동시에 사용하면 일관성 유지가 어려움
• 사용 예
  • 데이터베이스와의 직접적인 통신이 필요한 경우(ex, MySQL, PostgresSQL, MongoDB)
  • JPA, MyBatis 등을 활용한 데이터 관리가 필요한 경우
  • 비즈니스 로직과 데이터 접근 로직을 명확하게 분리해야 하는 경우

 

---

 

DTO(Data Transfer Object)

계층 간 데이터를 전달하는 역할

 

• 특징

- 데이터를 가공하여 원하는 형태로 전달하는 데 중점을 둠
- 주로 Contoller와 Service 계층 간, API 응답 데이터로 활용
- 데이터 전달이 목적이며 로직을 포함하지 않음
- 불필요한 엔티티 필드를 제외하고 필요한 데이터만 포함할 수 있음
- 일반적으로 getter / setter가 포함됨
- 직렬화(Serialization) 가능하여 JSON 또는 XML로 변환 가능

 

• 장점
  • 네트워크 비용 절감 → 필요한 데이터만 전달하여 성능 최적화
  • 보안성 증가 → 민감한 데이터를 감출 수 있음
  • 프레젠테이션 계층과의 독립성 보장 → 엔터티 변경이 UI에 영향을 주지 않음
• 단점
  • DTO를 추가하면 코드 복잡성이 증가할 수 있음
  • 수동으로 매핑해야 할 경우 오버헤드 발생 가능(ex, ModelMapper, MapStruct 필요)
• 사용 예
  • 클라언트와의 API 통신에서 JSON으로 데이터를 주고 받음
  • 다른 시스템 간 데이터 전달이 필요한 경우 (ex, 마이크로서비스 간 통신)
  • DB 엔터티 모델을 그대로 노출하지 않고 가공해야 하는 경우

 

 

---

 

VO(Value Object)

VO는 불변(Immutable) 객체로, 값을 표현하는 데 초점을 맞춘 객체

 

• 특징

- VO는 동일한 값을 가지면 같은 객체로 간주되며, 객체의 상태가 변하지 않도록 설계
- 불변성(Immutable): 생성된 후 값이 변경되지 않음
- 동등성(Equality) 비교: equals()와 hashCode()를 오버라이딩하여 동등성 비교를 수행
- 도메인 모델에서 사용: 비즈니스 로직에서 값의 일관성을 유지하기 위해 활용됨
- 주로 읽기 전용으로 사용됨

 

• 장점
  • 데이터 무결성 유지: 값이 변경될 수 없어 사이드 이팩트 방지
  • 멀티스레드 환경에서 안전: 불변성이 보장되므로 동기화 필요 없음
  • 객체를 캐싱하여 활용 가능: 같은 값을 가진 객체를 재사용 가능
• 단점
  • 값 변경이 필요한 경우 새로운 객체를 생성해야 함 → 성능 오버헤드 발생가능
  • 메모리 사용량 증가 가능: 새로운 객체가 지속적으로 생성될 경우 메모리 부담 증가
• 사용 예시
  • 금액, 좌표, 날짜 등 변경될 필요가 없는 값 표현(ex, Money, Address, Point)
  • 데이터 무결성이 중요한 경우 (ex, 주문 상태, 통화 단위)
  • equals() 비교가 필요한 경우(ex, 캐싱, 중복 제거)

 

 

VO vs DTO

• Dto는 가변의 성격을 가진 클래스이며 데이터 전송을 위해 존재(getter/setter)
• Vo는 값 그 자체의 의미를 가진 불변 클래스(Read-Only)를 의미 == getter만 존재
• Dto는 인스턴스 개념이라면, Vo는 리터럴 개념 즉, Vo는 특정한 비즈니스 값을 담는 객체이고, Dto는 Layer간의 통신 용도로 가직

---

 

Entity

데이터베이스 설계와 프로그래밍에서 하나의 객체 or 테이블에 해당하는 개념 (실제 DB 테이블과 1:1로 매핑되는 클래스)

 

• 특징

- DB 테이블 내에 존재하는 컬럼만을 속성(필드)으로 가져야 함
- 현실 세게의 개체(Entity)를 개체로 추상화
- 데이터베이스에서는 하나의 테이블로 독립된 역할을 가짐
- 최대한 외부에서 Entity클래스의 getter에 접근하지 않도록 내부에서 필요한 로직의 method를 구현해야 함
  (Domain Logic만 가지며 Presentation Logic을 가지고 있어서는 X)

 

• 장점
  • 재사용성: Entity 클래스를 설계하면 여러 비즈니스 로직에서 동일한 데이터 모델을 재사용 가능
  • ORM을 통해 데이터베이스 독립성 강화: Entity 클래스를 사용하면 코드와 데이터베이스 간의 의존성을 줄이고 데이터 베이스를 쉽게 교체 및 확장이 가능함
  • 데이터 무결성 유지: 데이터의 상태(Vaild/Invaild)를 유지할 수 있어 데이터 무결성 보장
• 단점
  • 복잡한 설계: 다수의 Entity와 관계가 얽히면 설계가 복잡해지고 유지보수가 어려워질 수 있음
  • 변경 관리 어려움: Entity 구조가 변경되면, 관련 비즈니스 로직과 데이터베이스 설계를 모두 변경해야 함

 

Entity vs VO

특성	Entity	VO(Value Object)
식별방법	고유한 식별자(ID) 로 객체를 구분	속성 값이 동일하면 동일한 객체로 간주
상태변화	상태가 변할수 있음	불변객체로 상태가 변하지 않음
비즈니스 로직 포함 여부	비즈니슥 로직을 포함할 수 있음	비즈니슥 로직을 포함할 수 있음
영속성	데이터베이스 테이블과 매핑됨	영속성과 관계없이 사용됨

 

 

 

언젠가 아디오스

 

 

 

 

참고
- https://gofo-coding.tistory.com/entry/Entity-DTO-DAO-VO
- https://velog.io/@ygreenb/DTO-VO-Entity