Dto 설계 문의

안녕하세요. 샘플강의 보고 감명받아 영환님 모든 강의를 수강하고 몇일 전 완강을 했습니다.

좋은 강의 다시 한번 감사합니다.

다름이 아니라 문의드릴 내용은 다음과 같습니다. Dto 설계와 구현인데요

public class ScheduleDto {
 ...
  private List<WatchDto> watchs;

@QueryProjection
  public ScheduleDto(..., List<WatchDto> watchs) {
...
 this.watchs = watchs;
 }

위와 같이 Dto구성하고,

검색 Repository에서 아래와 같이 watchs 를 구성한다고 했을때

@Override
  public Page<ScheduleDto> searchPage(ScheduleSearchCond cond, Pageable pageable) {
    List<ScheduleDto> content = qf.select( new QScheduleDto(
                                   ...
                                    schedule.watchs // << [이부분 구성을 어떻게 처리해야하는지 ??]
                                    ))
                                  .from(schedule)
                                  .fetch();

schedule.watchs는 List 인데, 어떻게 작성되어야 하는지 궁금합니다.

그리고 Dto 설계상 "List<someDto> xxx" 로 멤버변수를 만들면 안되는지도 궁금합니다.

강의에 해당 예시가 안보여서, 설계가 문제있는지도 궁금해서요.

아무쪼록 요즘같은 시기에 건강 유의하시고, 다음 강의도 기대하겠습니다.

개인적으로는 결제 관련 백엔드 강의면 좋겠다 싶은 희망사항도 있습니다.

수고하세요 ^^

Half Lemon님 드디어 완강하셨군요^^ 축하합니다.

DB에 아마 다음과 같이 들어가있겠네요

Schedule 테이블

Watche 테이블

W1 (S1 소속)

W2 (S1 소속)

둘을 조인해서 조회하면 아마 두줄로 조회 될꺼에요.

S1, W1

S1, W2

답변을 드리면, 엔티티를 조회할 때는 fetch join등을 사용해서 객체 그래프를 조회하기 때문에 컬렉션도 함께 조회할 수 있습니다.

그런데 Dto로 조회할 때는 데이터를 RDB의 결과에 맞게 한줄로 풀어서 조회하기 때문에, 원하시는 모양으로 조회하기는 어렵습니다. (사실 엔티티를 조회할 때 사용하는 fetch join도 DB에서 데이터를 조회할 때는 한줄로 풀어서 가져오지만, JPA에서 정리를 해줍니다. fetch join은 이걸 자동으로 해주기 때문에 개발자가 편리한 것이지요)

그래서 DTO도 (S1, W1), (S1, W2) 이런식으로 우선 받아야 합니다. 그 다음에 다시 DTO를 만들어서 원하시는 모양으로 변경해야 합니다.

이렇게 고민하셨으니, 이제 활용2편의 DTO 최적화 부분을 다시보시면 DTO로 조회하는 기능의 한계점과 돌파 방법이 보이실꺼에요^^

감사합니다.

인프런 커뮤니티 질문&답변