728x90
이번 포스팅은 프로젝트를 하다가 Dto에 대해서 공부한 지식을 정리하고자 작성한 글입니다.
DTO란 ❓
DTO(Data Transfer Object)는 애플리케이션의 다양한 레이어나 시스템 간에 데이터를 전송하기 위해 사용하는 단순화된 데이터 구조입니다.
DTO는 데이터 전송에 필요한 필드만 포함하며, 비즈니스 로직이나 메서드는 포함하지 않아 데이터의 효율적 전송과 관리가 용이합니다.
DTO와 Entity를 분리하는 이유
- 관심사의 분리
- Entity는 데이터베이스와의 상호작용을 관리하고, 데이터의 저장, 조회, 업데이트, 삭제를 처리합니다.
- DTO는 클라이언트와 서버 간의 데이터 전송을 처리하며, 사용자 인터페이스와 애플리케이션의 내부 로직 간의 데이터를 매핑합니다.
- 유연성 향상
- DTO와 Entity를 분리하면, 데이터 전송 구조를 변경하더라도 데이터베이스
모델에 영향을 미치지 않습니다. 이를 통해 데이터 모델의 변경 없이 클라이언트 요구 사항에 맞게 DTO를 조정할 수 있습니다.
- DTO와 Entity를 분리하면, 데이터 전송 구조를 변경하더라도 데이터베이스
- 보안
- DTO를 사용하면 데이터베이스 엔티티의 민감한 필드(예: 비밀번호, 내부 식별자 등)를
클라이언트에게 노출하지 않을 수 있습니다. - DTO는 필요한 데이터만 포함할 수 있어 보안성을 높일 수 있습니다.
- DTO를 사용하면 데이터베이스 엔티티의 민감한 필드(예: 비밀번호, 내부 식별자 등)를
- 데이터 전송 최적화
- DTO는 필요한 데이터만 포함하므로, 네트워크 대역폭을 절약하고 성능을 최적화할 수 있습니다. 엔티티는 모든 필드를 포함하기 때문에 전송하는 데이터의 양이 많을 수 있습니다.
- 변환 및 매핑
- DTO와 Entity를 분리하면, 데이터 변환 및 매핑을 명확히 할 수 있습니다.
- 예를 들어, Entity를 DTO로 변환할 때 추가적인 데이터 처리나 변환 로직을 포함할 수 있으며, 이로 인해 비즈니스 로직과 데이터 전송 로직을 분리할 수 있습니다.
- 유지보수성과 테스트 용이성
- 엔티티와 DTO를 분리하면 각 객체의 책임이 명확해지고, 유지보수와 테스트가 용이해집니다.
- 엔티티는 데이터베이스와의 상호작용에만 집중하고, DTO는 데이터 전송과 관련된 기능에만 집중할 수 있습니다.
- 클라이언트와 서버의 독립성
- DTO는 클라이언트와 서버 간의 데이터 전송을 담당하므로, 클라이언트의 요구에 맞게 DTO를 조정할 수 있습니다.
- 서버의 데이터베이스 모델이 변경되더라도
클라이언트 측에는 영향을 미치지 않게 할 수 있습니다.
위와 같이 Entity를 그대로 사용하게되면 문제점이 많습니다. 그래서 보통 Entity를 DTO로 변환하게 되는데, 이러한 DTO도 그대로 사용하면 문제를 일으킬 수 있습니다.
DTO(Data Transfer Object)를 그대로 사용하는 것이 문제를 일으킬 수 있는 이유를 요약하면 다음과 같습니다.
- 데이터 캡슐화 부족
- DTO는 데이터 전송을 위해 설계된 간단한 객체로, 비즈니스 로직이나
데이터 검증을 포함하지 않기 때문에 데이터의 무결성을 보장하기 어려움.
- DTO는 데이터 전송을 위해 설계된 간단한 객체로, 비즈니스 로직이나
- 관심사의 분리 부족
- DTO는 데이터 전송 목적으로 사용되며, 비즈니스 로직이나 데이터 저장과 관련된 책임과 분리되어야 하는데, 이를 그대로 사용하면 비즈니스 로직과 데이터 전송 로직이 혼합되어 유지보수가 어려움.
- 안전성 문제
- DTO를 직접 사용하는 경우, 클라이언트가 서버에 보내는 데이터에 대한 검증이 부족할 수 있어, 데이터의 올바름이나 악의적 조작을 방지하기 위한 추가 검증이 필요함.
- 유연성 부족
- 비즈니스 요구사항 변경 시 DTO와 도메인 모델 간의 매핑 조정이 어려워져, 변경에 대한 대응이 복잡해질 수 있음.
- 테스트 어려움
- DTO는 비즈니스 로직을 포함하지 않기 때문에, DTO를 테스트하는 것만으로는 비즈니스 로직이 제대로 작동하는지 확인하기 어려움.
위와 같은 이유가 있기 때문에 DTO와 도메인 모델간의 문제를 해결하려면 다양한 방법은 다음과 같습니다.
- 매퍼 사용 (예: MapStruct, ModelMapper)
- 서비스 계층 도입
- DTO의 전용 변환 메서드
- 도메인 이벤트 사용
- 애그리게이트 루트 및 레포지토리 패턴
- 유효성 검사 및 검증
- Adapter 패턴
위의 방법 중 공부를 하고 가장 적합한 방법을 찾아서 프로젝트에 적용해 봐야겠다..!
'TIL,일일 회고' 카테고리의 다른 글
[TIL, 일일 회고] 2024-08.11 - 캐싱 전략 (0) | 2024.08.12 |
---|---|
[TIL, 일일 회고] 2024.08.11 - MapStruct의 편리함 (0) | 2024.08.11 |
[TIL, 일일회고] 2024.08.09 - @Data를 지양하자 (0) | 2024.08.09 |
[TIL, 일일 회고] 2024.08.08 - gitignore (gradle-wrapper.jar &properties) (0) | 2024.08.08 |
[TIL,일일 회고] 2024.08.07 - Spring Cloud Stream이란❓ (0) | 2024.08.07 |