프레임워크/Spring Boot
[Spring] DO(Entity), DTO
김꿍디꿍디
2024. 5. 16. 10:44
반응형
DO(Entity)? DTO?
Domain Object (= Entity)
= DB 데이터 원본
- setter를 가질 수 없는 것은 아니다.
- 수정 용도 등 꼭 필요로 하는 setter는 가질 수 있다.
- ex. set *** , update **** (매개변수 1~2개 +@)
- 수정 용도 등 꼭 필요로 하는 setter는 가질 수 있다.
DTO(Data Transfer Object)
= Domain Object 사본
- 추가 필드 혹은 제외 필드를 가질 수 있다.
- 계산된 데이터를 가질 수 있어야 한다.
- 데이터 변환도 일어날 수 있다.
- setter를 가질 수 있다.
FE ~ DB 로 데이터 전송 과정 중 DTO <-> DO 변환 위치
* 개인의 주관적인 생각입니다. 다르게 생각하시는 분은 댓글 남겨주시면 감사하겠습니다 :)
Service 로직에서 변환해야한다고 생각한다.
그 이유는 아래와 같다.
FE -> DB
- FE -> Controller -> Service : 클라이언트에서 원하는 필드로 입력 받은 DTO 전달
- Service -> Repository -> DB: Entity에 맞게 변환한 DO 전달하여 DB 저장
DB -> FE
- DB -> Repository -> Service : DB의 데이터 원본를 R에서 꺼내서 S로 DO 전달
- Service -> Controller -> FE : DO를 클라이언트에서 원하는 필드로 계산한 DTO로 변환하여 FE에 전달
Service 에서 변환 시 장단점
장점 👍🏻
- 단일 장소에서 변환 작업 관리
Service는 비즈니스 로직을 관리하는 곳이므로, DTO와 Entity 간의 변환 작업을 Service 내에서 수행하면 변환 작업을 단일한 장소에서 관리할 수 있다. - 코드 중복 감소
Service 내에서 DTO와 Entity 간의 변환 작업을 수행하면, 여러 Controller 메소드에서 동일한 변환 작업을 반복할 필요가 없어진다. - 비즈니스 로직과 분리
DTO와의 변환 작업을 Service에서 수행하면, 비즈니스 로직과 변환 로직을 분리하여 코드를 관리할 수 있다.
단점 👎🏻
- Service의 복잡도 증가
Service에 변환 작업까지 포함되면 역할이 복잡해질 수 있다. - 코드 재사용성 하락
Service에서 특정 DTO에 의존하게 되면 여러 종류의 Controller에서 해당 Service를 이용할 수 없어 코드 재사용성이 떨어지게 된다.
Controller 에서 변환 시 장단점
장점 👍🏻
- Presentation Logic 분리
DTO는 주로 클라이언트에게 데이터를 전달하기 위한 용도로 사용되므로, Controller에서 DTO와의 변환 작업을 수행하면 Presentation Logic을 Controller 내부로 격리시킬 수 있다. - Controller 레벨에서 유효성 검사
Controller에서 DTO와의 변환 작업을 수행하면, 변환 과정에서 유효성 검사를 수행할 수 있다. 이로써 더욱 엄격한 데이터 유효성을 적용할 수 있다. - Service의 독립성 유지
Service 레이어에서 Entity에만 의존하고 DTO 변환 작업을 수행하지 않으면, Service 레이어의 독립성과 재사용성이 높아진다.
단점 👎🏻
- 반복적인 작업
DTO와 Entity 간의 변환 작업은 여러 Controller 메소드에서 반복적으로 수행되어 코드 중복이 발생한다. - 비즈니스 로직과 혼재
DTO와의 변환 작업을 Controller에서 수행하면, 비즈니스 로직과 DTO 변환 로직이 혼재되어 코드의 가독성과 유지보수성이 저하된다.
구현 방법
DTO -> Entity
- 필드 추가 및 삭제를 고려한 DTO 클래스 생성
- 변환
- 생성자
- setter
- Model Struct
- copyProperties
- MapStructure
- 원하는 위치에서 구현
참고
반응형