작성
·
450
0
회원가입과 비밀번호 암호화 - 1에 5분 10초 정도 쯤에
dto를 서비스 계층으로 바로 넘기는 것이 안 좋다고 호돌님께서 말씀하셨습니다. 그래서 궁금증을 해결해 보고자 검색을 해봤습니다. 근데 dto를 컨트롤러 계층에서 엔티티로 변환하고 서비스 계층으로 넘겨야한다는 의견도 있고 컨트롤러에서 변환하고 넘기는 것보다 서비스 계층에서 dto를 변환해야 한다는 의견이 있는데
호돌님께서 말씀하신 것이 제가 고민하고 있는 것이 맞는지 알고 싶고 호돌님께서는 왜 dto를 서비스 단에 바로 넘기는 것이 안 좋다고 했는지 궁금합니다.!! 의견이 너무 갈려서 뭐가 맞는 방법인지 헷갈리네요
답변 2
0
안녕하세요. 호돌맨입니다.
질문을 남겨주셔서 감사합니다.
웹을 통해 넘어온 DTO를 서비스로 넘기게 되면 서비스에서 해당 DTO를 '알아야'하는 상황이 됩니다.
이는 의존 역전 원칙에 관해 찾아보시면 좋을것 같습니다.
추천 키워드
DIP (의존 역전) 원칙
객체지향 원칙
https://koseungbin.gitbook.io/wiki/books/undefined/part-2.-di/solid/dependency-inversion-principle
감사합니다.
0
안녕하세요, 인프런 AI 인턴입니다.
김영광님, DTO(Data Transfer Object)를 서비스 계층으로 바로 넘기는 것에 대한 호돌님의 의견이 궁금하신 것으로 이해했습니다. Spring Data에서 DTO 사용법과 관련하여, 클래스 기반의 DTO 사용 방식으로는 JPQL이나 @Query
어노테이션으로 DTO를 직접 사용하는 방법이 있습니다. 예를 들어, 아래와 같이 Java Record를 이용해 DTO를 정의할 수 있습니다.
record NamesOnly(String firstname, String lastname) {
}
이렇게 정의된 DTO는 프록시를 사용하지 않고, 쿼리 실행 시 필요한 필드만 로드하도록 최적화될 수 있습니다. 여기서 중요한 점은 클래스 기반의 프로젝션은 JPQL의 생성자 표현식으로 한정되며, 네이티브 쿼리와는 호환되지 않는다는 것입니다. 자세한 내용은 Spring Data JPA 문서에서 확인하실 수 있습니다.
참고 링크: Class-based Projections (DTOs)
귀하께서 언급한 조언의 차이점은 아키텍처의 층별 역할과 관련된 DTO의 전달 방식에 따를 수 있습니다. 여러 개발자와 팀은 각자의 경험과 프로젝트의 특징에 맞추어 DTO를 어느 계층에서 변환할지 결정합니다. 보편적으로는 서비스 계층에서 도메인 객체로의 변환을 수행하여, 서비스 계층이 비즈니스 로직과 데이터 간의 변환 책임을 갖기도 합니다. 다만 이는 상황에 따라 다를 수 있으니, 귀하께서 필요로 하는 구체적인 상황에 대해 더 많은 정보를 고려해보시는 것이 좋을 것입니다.