DTO Entity간 변환 질문

Question

안녕하세요. 막 백엔드에 입문해 혼자 공부중인 대학생입니다.첫 공부 프로젝트로 CRUD를 지원하는 게시판을 만들던 중에 설계상 궁금한 점이 생겼습니다.먼저, Entity에 Setter를 두는것은 좋지 않다는 글을 많이 봐서 Getter와 빌더 패턴을 사용한 생성자만 두었습니다.구현 과정에서 &#64;ModelAttribute를 사용해 컨트롤러에서 폼 데이터를 바인딩 하려고 하니까, 엔티티에 Setter가 없어서 제대로 작동하지 않았습니다.이 문제에 대한 해결 과정에서 생긴 질문입니다.이렇게 Setter가 필요해진 상황에서 DTO를 도입하는 것이 옳은 접근 방법일까요? (DTO는 보통 API를 만들 때 반환 용도로 사용하는게 일반적이라고 들었습니다.)DTO와 Entity간 변환 작업은 어느 계층에서 담당해야 할까요? (컨트롤러, 서비스, 리포지토리, 엔티티)2번에 대해서, 저는 별도의 패키지로 분리시켜 Mapper처럼 toEntity, toDTO만 담당하는 클래스를 만들었습니다. 그 다음 스프링 빈으로 등록한 뒤 DI를 통해 컨트롤러에서 사용하고자 생각했습니다. 이 접근에 문제가 있을지 여쭤보고 싶습니다.

짱구올시다 · Answer

엔티티에 setter를 추가하기 보단 DTO를 별도로 두는 발상은 괜찮은 방향이라고 생각됩니다. 실제로도 많이 쓰이는 방법이구요. DTO는 계층 간 데이터 전달을 위해서 사용된다고 생각하시면 됩니다.DTO 자체가 엔티티로의 변환을 맡으면 될 것 같습니다. DTO가 엔티티 보다 저수준의 객체이니 더욱 고수준의 엔티티를 참조하는 건 문제가 되지 않습니다.별도의 변환 객체를 두는 것도 괜찮은 접근이라고 생각됩니다.

초무쿤 · Answer

도메인모델을 두시면 좀 명확해집니다.DTO <-> 도메인모델 <-> 데이터모델(Entity,VO)CustomerResponse <-> Customer <-> CustomerEntity— charGPT 의견도메인 모델을 사용하는 경우, 비즈니스 도메인의 개념과 규칙을 표현하기 위해 도메인 객체를 사용합니다. 도메인 모델은 비즈니스 로직을 포함하고, 도메인 규칙과 행위를 캡슐화하여 비즈니스 요구사항을 표현하고 해결하는 데 도움이 됩니다. 이러한 도메인 모델을 사용하면 다음과 같은 이점이 있을 수 있습니다:1. 응집성과 유지보수 용이성: 도메인 모델은 비즈니스 도메인의 개념을 객체로 표현하므로, 도메인의 응집성을 높일 수 있습니다. 이는 코드의 가독성과 유지보수 용이성을 향상시킵니다. 도메인 모델을 사용하면 비즈니스 요구사항의 변경에 대응하기 쉽고, 도메인 모델 자체의 변경이 다른 계층에 미치는 영향이 제한됩니다.2. 비즈니스 로직의 중앙 집중화: 도메인 모델을 사용하여 비즈니스 규칙과 동작을 한 곳에서 중앙 집중화할 수 있습니다. 이는 비즈니스 로직의 일관성과 유지보수성을 높여줍니다. 도메인 모델을 사용하면 비즈니스 규칙을 명확하게 표현하고, 도메인 모델 내에서 이러한 규칙을 조작할 수 있습니다.3. 도메인 모델의 재사용성: 도메인 모델은 비즈니스 도메인을 추상화하고, 도메인 모델 내에서 비즈니스 로직을 캡슐화합니다. 이는 도메인 모델의 재사용성을 높여줍니다. 동일한 도메인 모델을 다른 애플리케이션이나 서비스에서도 활용할 수 있으며, 도메인 모델을 통해 비즈니스 도메인의 일관성을 유지할 수 있습니다.DTO와 도메인 모델은 데이터 전송을 위한 목적과 비즈니스 도메인을 표현하는 목적에 따라 사용됩니다. DTO는 데이터 전송을 위한 목적으로 사용되며, 데이터 전송을 위해 필요한 필드와 메서드를 가지고 있습니다. 도메인 모델은 비즈니스 도메인의 개념과 규칙을 표현하며, 비즈니스 로직을 포함하는 객체입니다.일반적으로 DTO와 도메인 모델은 서로 다른 목적과 범위에서 사용됩니다. DTO는 주로 서비스 계층과 클라이언트 사이에서 데이터 전송을 담당하고, 도메인 모델은 주로 도메인의 핵심 개념과 비즈니스 로직을 표현하고 처리합니다. 그러나 필요에 따라 DTO와 도메인 모델 사이에 매핑 레이어를 추가하여 데이터 변환을 수행할 수도 있습니다.

김을동 · Answer

저는 dto 를 parameter로 받고서비스에서 entity로 변환 후응답을 dto로 변환합니다.dto들에 static toEntity fromEntity 같은걸 구현해서 사용하고 있읍니다

감독님테스트가하고싶어요 · Answer

2번의 경우 정답은 없는 것 같습니다.controller쪽을 말하는 사람도 있고 service를 말하는 사람도 있어서요.https://tecoble.techcourse.co.kr/post/2021-04-25-dto-layer-scope/

장독깨기 · Answer

그냥 흘려 들으시고, 한 번쯤 생각을 한 번 해보세요.엔티티에 세터를 두면 왜 안 좋을까요. 세터를 안 쓰고 빌더 패턴을 쓰면 뭐가 좋을까요.세터나 빌더 패턴이나 엔티티 속성에 값을 셋 하는 겁니다. 다를 게 없다는 얘기죠.그리고, 자바 빈은 기본적으로 게터, 세터가 있어야 하는 것이 규칙입니다.그래야, 속성 값에 데이터를 넣어 줄 수 있거든요. 물론, 엔티티가 빈일 필요는 없겠지만,기본적으로 게터, 세터를 해석해서 값을 채워준다는 얘깁니다.프로그래밍을 한다는게 잘 알지도 못하는 이상한 규칙을 외우고 그걸 지키고 이런 것이 아닙니다.이유, 왜 이런 부분이 중요합니다.한 번 생각해보시라 오지랖 좀 부려 봤습니다. :)

DTO <-> Entity간 변환 질문

5개의 답변

기술 목록