[Spring] DTO를 사용하는 이유

Goals

• DTO란?
• DTO를 사용하는 이유

 

DTO란?

---

DTO는 Data Transfer Object의 약어로, 데이터 전송 객체를 의미한다. 다른 말로, 계층 간 데이터 전송을 위해 도메인 모델 대신 사용되는 객체이다. 이때, 계층이란 Presentation(View, Controller), Business(Service), Persistence(DAO, Repository) 등을 의미한다.

https://learn.microsoft.com/en-us/archive/msdn-magazine/2009/august/pros-and-cons-of-data-transfer-objects

 

DTO를 사용하는 이유

---

그럼 왜 도메인 모델(Entity) 대신 DTO를 사용하는 이유가 뭘까?

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

도메인 모델은 Data Access 계층에서 데이터가 저장되는 DB와 직접적으로 관련되어 있는 객체다. 테이블의 구조에 맞게 설계되는 도메인 모델은 초기 설계 후 되도록 최대한 수정되지 않는 것이 안정적인 모델이다.

그에 반해 Presentation 계층에서는 View의 요구 사항에 따라 전달되는 데이터의 구조가 자주 바뀔 수 있다.

게다가 도메인 모델은 비밀번호나 개인 정보같이 View에서는 노출하면 안되는 민감한 정보들도 가지고 있다. 이 객체를 굳이 View에 전달할 필요도 없고, 전달해서도 안되는 것이다.

이는 각 계층의 관심사가 달라서 생기는 차이다.

• Presentation Layer : 애플리케이션의 기능과 데이터를 사용자에게 제공
• Business Layer : 애플리케이션의 핵심 비즈니스 로직 및 나머지 두 계층 간에 전달되는 데이터 처리
• Data Access Layer : 데이터베이스와 상호 작용하는 역할

 

따라서 각 계층의 관심사에 맞게 데이터를 담는 객체도 구분을 지어줘야 한다. 이를 객체 지향에서는 관심사의 분리(Separation of Concerns, SoC)라고 한다.

DTO의 핵심 관심사는 이름 그대로 데이터의 전달이다. DTO는 데이터를 담고, 다른 계층 또는 다른 컴포넌트들로 데이터를 넘겨주기 위한 자료구조이다. 그러므로 Presentation 계층에 속한다.

반면에 도메인(Entity)는 핵심 비지니스 로직을 담는 비지니스 도메인의 영역의 일부이다. 그러므로 도메인(Entity)은 그에 따른 비지니스 로직이 추가될 수 있다. 즉, Business 계층에 속하며, 다른 계층 사이에서 전달을 위해 사용되는 객체가 아니다.

위처럼 DTO와 도메인(Entity)은 엄연히 서로 다른 관심사를 가지고 있고, 그렇기 때문에 분리하는 것이 합리적이며, 자연스럽게 의도치 않은 데이터 변경, 노출 및 오류를 예방할 수 있다.

다만, DTO의 사용 범위와 Entity와 DTO를 어느 계층에서 변환시키는 것이 합리적인 지에 대한 의견은 다양한 것 같다. 아래는 이에 대한 고민이 담긴 포스팅 들이다.

• https://hudi.blog/data-transfer-object/
• https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/
• https://www.inflearn.com/questions/139564/dto-사용시기에-대한-질문

 

클라이언트로부터 서버(Controller)의 호출을 최소화하기 위해

"리팩토링"의 저자로 유명한 마틴 파울러는 저서 *Patterns of Enterprise Application Architecture(P of EAA)*에서 DTO 를 소개하고 있다.(https://martinfowler.com/eaaCatalog/dataTransferObject.html)

우리가 원격 인터페이스로 작업을 할 때, 호출에 따른 비용은 매우 비싸다. 그렇기 때문에 우리는 요청의 횟수를 줄여야 하고, 이를 위해 한번의 요청에 더 많은 데이터를 전송해야 한다.

우리는 이를 수행하기 위해 많은 매개변수를 사용할 수 있다. 그러나 이것은 프로그래밍하기 어려운 방법일 뿐더러, JAVA에서는 반환 값으로 여러 개의 값을 받을 수 없으므로 더욱 불가능한 일이라 할 수 있다.

그렇기 때문에, 우리는 요청에 대한 모든 데이터를 보관할 수 있는 데이터 전송 객체, DTO를 만들어 사용한다.

 

즉, 마틴 파울러가 말하는 DTO 의 주요 목적은 한 번의 호출로 여러 매개 변수를 일괄 처리해서 서버의 왕복을 줄이는 것

예를 들어, 어느 상품 Q&A 페이지에서 View를 구성하기 위해서는 아래 3개의 API를 호출해야만 한다고 가정해 보자.

• 상품소개 API  1개
• Q&A  API 1개
• 유저 API 1개

 

이렇게 서버와 클라이언트가 3번의 통신을 하는 것도 틀린 방법은 아니지만, 1번의 통신으로 줄일 수 있는 방법이 DTO를 사용하는 방법이다.

위 3개의 API가 전송할 데이터들을 모두 담고 있는 DTO를 만들어 API 1번의 호출로 바꾸는 것이다.

물론, 그 과정을 살펴보면, 데이터베이스를 접근하는 횟수는 같을 것이고, Entity를 DTO로 변환하는 과정과 중복 코드가 발생하게 된다.

이런 것을 다 감수하더라도 서버와 클라이언트 간의 호출 비용은 크기 때문에 DTO를 사용하는 편이 더 효율적일 수 있다는 것이다.

이에 대한 자세한 예시는 아래 포스팅 글을 참고

• https://e-una.tistory.com/72#1.2.2. 관심사의 수평적 분리
• https://kafcamus.tistory.com/13

 

References

• https://hudi.blog/data-transfer-object/
• https://velog.io/@boo105/Entitiy-와-DTO-의-분리
• https://e-una.tistory.com/72#1.2.2. 관심사의 수평적 분리
• https://tecoble.techcourse.co.kr/post/2020-08-31-dto-vs-entity/
• https://kafcamus.tistory.com/13
• https://kafcamus.tistory.com/12