(개발지식) 4 - DTO 와 VO 의 차이에 대한 논문

 

Comparative Analysis of DTO and VO: Enhancing Data Transfer

 

 

5조 박00, 송00, 이00, 이00, 표00

 

---

  DTO와 VO는 각각 데이터 관리와 응용 프로그램의 계층 간 통신을 용이하게 하는 데에 다른 목적을 가지고 있다. 이 논문은 DTO와 VO의 개념에 대해 자세하게 설명하고 주요 차이점에 대해 포괄적으로 탐구하고자 한다. 그에 따라서 DTO와 VO가 서로 다른 객체 임을 명확히 구분하고, 예시를 통해 혼동을 줄이고 이들 개념의 올바른 사용에 대한 이해를 제시하고자 한다.

  본고는 총 3 장으로 구성되어 있다. 제 1 장 서론에서는 연구의 목적과 배경에 대해서 설명하였다. 제 2 장 본론에서는 DTO와 VO의 정확한 개념을 정리하고 예시를 들어 둘 의 차이점을 명시하였다. 제 3 장 결론에서는 본 논문의 전반적인 내용에 대하여 총괄적인 평가를 하였다.

---

Ⅰ. 서론

  소프트웨어 시스템은 점점 복잡해지고 있으며, 그에 발맞춰 강력하고 효율적인 데이터 처리 메커니즘이 필요하다. DTO와 VO는 이러한 발전에 대응하기 위해 중요한 설계 패턴으로 등장했다. 데이터 전송 객체로 알려진 DTO(Data Transfer Object)를 ‘Core J2EE Patterns: Best Practices and Design Strategies’ 책의 초판에서 실수로 VO(Value Object)로 정의했 다.

---

The value object functions only as a data transfer object; it has no responsibility with respect to security, transaction, and business logic. (Dan Malks, January 1, 2001)

 

<자료> Core J2EE Patterns: Best Practices and Design Strategies

---

 

  이로 인해 데이터 전송 객체를 VO로 인식하는 사람이 많아졌다. 혼동되는 것을 막고자 ‘Core J2EE Patterns’ 책의 두 번째 판에서 데이터 전달용 객체를 TO로 정의하고 수정했지 만 이미 "Value Object"라는 이름은 유명해져 여전히 DTO의 별칭으로 잘못 사용되고 있다. 그래서 현재도 데이터베이스를 저장하고 데이터를 전달할 때 사용되는 DTO와 VO를 혼동하여 쓰는 경우가 많다. 하지만 DTO와 VO는 다른 객체이고 정확히 구분해야 할 필요성이 있 으며, 이름이 다른 것처럼 DTO와 VO는 엄연히 다른 용도와 특징을 가지고 있다. 본 연구 의 목적은 DTO와 VO에 대한 개념 정의를 통해 두 개념을 명확히 구분하고 예시를 통해 혼 동을 줄이고 해당 개념을 올바르게 사용함에 의의를 둔다.

 

Ⅱ. 본론

- DTO(Data Transfer Object)의 개념

  DTO는 Data Transfer Object의 약자로 마틴 파울러(Martin Fowler)가 ‘Patterns of Enterprise Application Architecture’라는 책에서 처음 소개한 엔터프라이즈 애플리케이션 아키텍처 패턴의 하나이다. 계층간 데이터 교환을 위해 사용하는 객체로, 요청 데이터 (클라이언트 → 서버)와 응답 데이터 (서버 → 클라이언트)의 전달자(Transfer) 역할을 한다.

 

<자료> Patterns of Enterprise Application Architecture p.306

[그림 1] DTO에 대한 모식도

 

  DTO는 로직(불필요)을 가지지 않는 데이터 객체이고, getter/setter 메서드만 가진 클래스이다. setter를 가지고 있어 값이 변할 수 있지만 불변 객체로도 활용이 가능하다. setter를 포함하는 경우는 값을 변경할 수 있고 setter가 아닌 생성자를 이용해서 초기화하는 경우 불변 객체가 될 수 있다. DTO를 사용하는 이유는 코드의 간결성을 위해서이다. 요청 데이터가 많은 경우 데이터 전달을 위해 단순히 파라미터의 수를 늘리는 방법은 비효율적이다. 특히, 자바의 경우는 리턴값이 하나이기 때문에 어려움이 있다. 그리고 HTTP 요청데이터가 많은 경우 각 데이터에 대한 개별 호출은 클라이언트와 서버간의 왕복 시간이 소모된다는 문제점이 있으며 비용도 비싸진다. DTO를 이용해 하나로 전달받으면 코드가 간결해질 수 있고, 호출 횟수도 줄어들게 되어 효율적이다.

 

[그림 2] DTO(Data Transfer Object)의 예시 코드 및 출력 결과

 

 

- VO(Value Objecet)의 개념

  VO는 Value Objecet의 약자로, 값 객체라는 이름답게 단순히 값만을 비교한다. 지폐의 일련번호(객체 주소)가 다르다고 해서 값이 가지는 가치가 달라지지 않는 것처럼 객체 안의 값은 변경 불가능(Immutable) 속성을 가지며, 불변이기 때문에 외부에서 값을 변경할 수 있게 해주는 setter 메서드를 사용할 수 없다. 또한 DTO와는 달리 getter/setter 외에도 다른 메서드를 포함할 수 있다.

 

[그림 3] 마틴 파울러가 강조한 VO의 특징

 

  VO 코드를 만들 때 핵심적으로 해야 할 일은 값 비교를 할 때 같은 객체라는 것을 보장하기 위해 equals()와 hashcode()를 오버라이딩하는 것이다. 객체의 값으로 비교하기 위해 String 클래스의 equals()가 했던 것처럼 equals() 메서드를 오버라이딩 하고, 객체의 주소를 정수로 바꾼 형태인 hashcode를 이용하는 Collection Framework(HashSet, HashMap 등)을 사용할 때 문제가 생기는 것을 방지하기 위해 hashCode() 메서드를 오버라이딩 해주어서, 값이 같으면 같은 hashCode를 생성하게 만들어 비교가 용이하게 해 준다.

 

[그림 4] HashSet, HashMap의 객체 비교 방식

 

[그림 5] VO(Value Object)의 예시 코드 및 출력 결과

 

 

- DTO와 VO의 차이점

  DTO와 VO는 현대 소프트웨어에서 중요한 역할을 하는 객체로서, 데이터 표현과 전달에 핵심적이다. 이 둘은 데이터 전송을 목적으로 하지만 구체적인 특성에서 차이가 있다. DTO는 주로 레이어 간 데이터 전송을 위해 사용되며, 역할 분리와 계층 간 의존성 최소화를 촉진하는 데 중점을 둔다. 반면 VO는 어떤 레이어에서도 사용할 수 있으며, 값 자체를 표현한다. 이로써 VO는 불변 객체로서 특정 일관성을 유지하고 데이터 무결성을 향상시킨다. DTO는 가변 객체로서 생성 후 상태를 변경할 수 있다. 그러나 setter 메서드를 사용하지 않고 생성자를 통해 속성 값을 초기화하면 불변 객체로서 안정적인 이점을 가질 수 있다. DTO는 데이터 표현을 위한 정렬, 직렬화 등의 기능을 제공할 수 있지만, 그 외의 기능은 가지지 않는다. 반면 VO는 특정 비즈니스 로직을 포함할 수 있다. 예를 들어, VO가 "주문"을 나타낸다고 가정해보면, 주문 VO는 주문의 상태, 금액, 날짜 등의 속성을 포함한 비즈니스 로직을 가질 수 있다. 이를 통해 VO는 데이터 표현과 함께 특정 비즈니스 도메인에 대한 로직을 포함할 수 있다. DTO는 데이터 전송을 위한 객체로 사용되기 때문에 속성 값이 같다고 해서 같은 객체로 간주되지 않는다. 서로 다른 DTO의 속성 값이 동일하더라도 별개의 객체로 처리한다. 이와 대조적으로 VO는 객체의 속성 값을 기반으로 동등성을 판단한다. VO는 equals()와 hashCode() 메서드를 오버라이드하여 속성의 값이 같은 경우에는 동일한 객체로 본다. DTO를 사용하면 응답 값을 변경에 따라 자유롭게 사용할 수 있고, 다른 클래스들에 영향을 미치지 않는다.

 

Ⅲ. 결론 및 제언

  본 연구는 DTO와 VO의 개념을 명확히 이해하고, 두 객체를 올바르게 사용함으로써 혼동을 줄이는 데 목적을 두었다. DTO는 데이터 전송을 위한 객체로 사용되며, 주로 레이어 간 데이터 교환에 활용된다. 데이터의 효율적인 전송과 코드의 간결성을 위해 사용되는데, 가변 객체로서 값을 변경할 수 있으며, setter 메서드를 통해 초기화할 수도 있다. 반면에 VO 는 값 객체로서 주로 불변 객체로 사용된다. 객체의 값을 비교하기 위해 equals()와 hashcode()를 오버라이딩하여 객체의 동등성을 판단하고, 데이터 무결성을 보장한다. VO는 DTO와 달리 특정 비즈니스 로직을 포함할 수 있으며, 데이터 표현과 함께 비즈니스 도메인에 대한 로직을 제공한다.

  따라서, 개발자들은 DTO와 VO의 용도와 특징을 명확히 이해하고, 각각의 객체를 올바르 게 사용함으로써 혼동을 줄여야 한다. DTO는 데이터 전송에 사용되는 객체로 데이터의 효율적인 전달과 코드의 간결성을 위해 활용되어야 하며, VO는 값 객체로서 데이터의 불변성 과 동등성 비교를 통해 데이터 무결성을 유지하고 비즈니스 로직을 제공하는데 활용되어야 한다.

  추후 연구에서는 DTO와 VO의 사용 사례에 대한 규칙 및 가이드라인을 제시하여 개발자들 이보다 명확하게 두 객체를 구분하고 활용할 수 있도록 함으로써 소프트웨어 시스템의 효율성과 유지보수성을 향상시킬 수 있는 방안을 모색할 필요가 있다.

 

[참고문헌]

[1] Dan Malks(2001) 외 2인. Core J2EE Patterns: Best Practices and Design Strategies First Edition

[2] Patterns of Enterprise Application Architecture p.306

[3] Patterns of Enterprise Application Architecture p.365

[4] https://velog.io/@chosj1526/VO-DAO-DTO-ENTITY%EC%9D%98-%EA%B0%9C%E B%85%90%EA%B3%BC-%EC%9E%A5%EB%8B%A8%EC%A0%90-%EB%B0%8F-%E C%B0%A8%EC%9D%B4

[5] https://hyeon9mak.github.io/DTO-vs-VO/

[6] https://jiwondev.tistory.com/113

[7] https://sas-study.tistory.com/404

[8] https://sas-study.tistory.com/402

[9] https://martinfowler.com/bliki/ValueObject.html

[10] https://goodgid.github.io/Java-Object-String-Equlas/

[11] https://dbjh.tistory.com/36

 

※ 해당 논문은 과제 형식으로 부여되어 논문 외 자료도 사용했음을 알려드립니다.

논문은 참고하되 반드시 출처 명시 부탁드립니다.