[04] DTO 사용하기 (양방향 관계에서 순환 참조 해결)

문제 상황)

Shop에 대하여 Slot를 생성했더니 이렇게 순환참조가 이뤄졌다.

양방향으로 설정해뒀더니 Slot 이 Shop을, 또 Shop이 Slot 을 무한 참조하는 것이다..

찾은 해결 방법)

① 양방향이 아니라 단방향으로 수정.

→ Shop에서 Slot을 수정하거나 조회하는 등의 관리를 해야하고,

영속성 전이도 필요하기 때문에 단방향으로 수정은 안될 것 같다.

 

② @JsonIgnore

③ @JsonManagedReference & @JsonBackReference

→ 두 방법 모두 이렇게 응답에 아예 포함되지 않는다.

 

실제 해결 방법)

위 방법도 괜찮겠지만 나는 아이디나 생성일과 수정일도 응답에 넘겨주고싶지않다.

그래서 DTO을 만들어 활용하기로 결정했다.

위와 같이 내가 보내주고 싶은 정보만 보내줄 수 있게 됐다.

예약상태랑 reservation은 나중에 같이 넘겨줄 수도 있을 것 같다.

우선은 Slot과 Shop부터 해결하자는 생각으로 reservation은 무시중..;;

 

---

DTO를 만드니 가장 고민이 됐던 부분이 Entity ↔ DTO 간의 변환이다.

나는 일단 RequestDTO와 ResponseDTO를 분리하지 않았다.

 

① 컨트롤러에서는 클라이언트로부터 DTO(request)를 받고 서비스에게 넘겨준다.

② 서비스 안에서 DTO를 Entity로 변환 후 repository를 호출하여 저장한다.

③ 저장하면서 반환된 Entity를 다시 DTO(reponse)로 변환하여 return 해준다.

 

나는 변환 과정을 일단 Builder 패턴을 이용해서 수동으로 진행해줬다.

(ModelMapper 등을 사용하는 방법도 있다고 한다.)

Builder가 자꾸 반복되는 게 보기에 깔끔하지 않은 것 같아서

Converter을 만들어서 따로 관리할까 생각도 든다.

 

언제 DTO를 변환할 것인지도 고민했다.

Controller에서? Service에서?

SOLID중 SRP(단일 책임 원칙)을 생각하면 Service.

SRP는 서로 책임 영역을 확실히 하자 = 결합도를 낮추자는 목적이 있는 것으로 이해했다.

 

컨트롤러의 책임: 요청 → 서비스 호출 → 응답 반환
서비스의 책임: 비즈니스 로직 수행

 

비즈니스 로직이라는 게 아직 정확하게 이해가 안 간다.

그러니까 어디서 변환할지 고민을 했겠지..

지금은 데이터를 어떻게 처리하고, 어떤 규칙으로 동작할지 결정하는 것이라고 이해중.