[데이터 처리와 DB연동] 1. DTO / VO(Entity) / DAO / Service는 왜 나누는가?

 

웹 애플리케이션을 만들면 결국 데이터가 필요하다.
게시글, 회원, 주문, 할 일 목록처럼 “저장하고 꺼내야 하는 정보”가 생긴다.

이때 중요한 건 단순히 “DB에 넣고 꺼내는 코드”가 아니라,
그 코드를 어떤 구조로 나눠서 유지보수 가능하게 만들 것인가이다.

그래서 보통 아래 네 가지 역할을 분리해서 생각한다.

• DTO
• VO(Entity)
• DAO
• Service

 

1) DTO: 계층 사이를 오가는 “전달용 데이터 묶음”

DTO(Data Transfer Object)는 이름 그대로 “전달용 객체”이다.

• 컨트롤러 ↔ 서비스
• 서비스 ↔ DAO
• 서버 ↔ 화면(JSP/API)

처럼 계층 사이에서 값을 주고받을 때 쓰는 택배 상자이다.

DTO의 특징은 보통 이렇다.

• 여러 값을 한 번에 묶어서 전달한다
• 필요하면 입력값 검증(스프링에서는 더 강하게)에도 쓰인다
• 로직을 넣기보다 “데이터 담기”에 집중한다

즉 DTO는 “역할”이 아니라 “운반”이 목적이다.

 

2) VO(Entity): DB 한 행(row)을 표현하는 “데이터 자체”

VO(Value Object) 또는 Entity는 DB의 한 행을 자바 객체로 표현한 것이다.

예를 들어 todo 테이블이 있다면
그 테이블의 한 행을 표현하는 Todo 같은 클래스가 VO/Entity 역할을 한다.

VO/Entity는 이런 성격이 강하다.

• DB 구조에 가깝다
• “데이터 그 자체”를 표현한다
• 보통 DAO가 이 객체 단위로 데이터를 다룬다

DTO가 “배송 상자”라면
VO/Entity는 “실제 물건”에 가깝다.

 

3) DAO: DB 접근을 전담하는 객체

DAO(Data Access Object)는 DB 접근 로직을 모아놓은 객체이다.

즉 DAO는 “데이터베이스와 직접 대화하는 계층”이다.

DAO가 하는 일의 예시는 이런 것들이다.

• insert/update/delete/select 실행
• JDBC로 Connection/PreparedStatement/ResultSet 처리
• 결과를 VO/Entity로 매핑해서 반환

핵심은 이것이다.

서비스/컨트롤러는 SQL이 어떻게 실행되는지 몰라도 된다
DB 접근은 DAO가 책임진다

 

 

4) Service: 비즈니스 로직(기능)을 묶는 계층

Service는 기능 단위 로직을 담당한다.

예를 들어 “Todo 등록” 기능이 있다면
그 기능이 단순 insert 하나로 끝나지 않을 수 있다.

• 입력값 검증
• 중복 체크
• 트랜잭션 처리
• 여러 DAO 호출 조합
• 정책(규칙) 적용

이런 “업무 규칙”을 모으는 곳이 Service이다.

즉 DAO가 “데이터 접근”이라면
Service는 “기능의 의미”를 담당한다.

 

 

전체 흐름

웹 MVC에서 일반적인 흐름은 이런 식이다.

1. Controller가 요청 파라미터를 받아 DTO를 만든다
2. Controller가 Service를 호출한다
3. Service가 필요한 정책/로직을 수행한다
4. Service가 DAO를 호출해 DB 작업을 수행한다
5. DAO가 DB 결과를 VO/Entity로 만들어 반환한다
6. 필요하면 Service가 VO/Entity를 DTO로 변환해 Controller에 준다
7. Controller가 View(JSP)에 전달한다

즉 역할을 나눠서 “책임 분리”를 만든다.

 

 

DTO와 VO를 왜 둘 다 만들까

여기서 현실적으로 제일 많이 나오는 질문이 이거다.

• “DTO랑 VO가 비슷한데 왜 둘 다 만들지?”

둘의 목적이 다르기 때문이다.

• DTO: 계층 사이 전달 / 입력값 중심 / 화면 중심
• VO(Entity): DB 모델 표현 / 저장/조회 중심

처음에는 귀찮아 보이지만
프로젝트가 커질수록 분리해 둔 구조가 더 유리해진다.

특히 스프링/JPA로 넘어가면
VO(Entity)는 필수 개념이 된다.

 

 

핵심 정리

• DTO는 전달용 데이터 상자이다
• VO(Entity)는 DB 한 행을 표현하는 데이터 자체이다
• DAO는 DB 접근을 전담한다
• Service는 기능(비즈니스 로직)을 묶는다
• 역할 분리를 하면 유지보수와 확장이 쉬워진다