코린이의 일기장

반려견의 돌봄 예약이 발생하면 고객 전용 돌봄 예약 엔티티와 돌봄사 전용 돌봄 예약 엔티티에 동일한 데이터가 삽입하게 된다.      현재 나는 고객 시점 돌봄 예약 엔티티(CustomerReservation)과 돌봄사 시점 돌봄 예약 엔티티(SitterSchedule)를 나누어 쓰고 있는 상태이고, 각각 엔티티가 서로 모두 공통적인 필드를 갖고 있는 상태이다. (사진 상에서는 예약한 고객(customer), 돌봄을 하게 될 돌봄사(sitter)를 공통적으로 갖고 있음.)돌봄사 시점 돌봄 예약 엔티티인 SitterSchedule이 고객 시점 돌봄 예약 엔티티(CustomerReservation)에 의존하지 않고, 따로 고객과 돌봄사의 정보를 갖고 있다. 이 상황에서 다르게 할 수 있는 방법이 또 하나 있..

개발을 하다가 회원에게 정보를 보여주기 위해서 나는 엔티티를 직접 조회한 후, 해당 조회한 엔티티를 Response 할 DTO로 변환하는 과정을 거쳤었다. 긴 설명보단 사진으로 보여주자면     첫 번째 서비스단 로직이 기존에 사용했던 코드이다. 리포지토리에서 엔티티를 직접 조회한 후 두 번째 사진인 Response DTO로 변환하는 과정을 거쳤었다. 근데 여기서 문제가 있단 걸 발견했다. DTO 클래스의 생성자를 보면 CareAvailableDate를 매개변수로 받아서 사용하고 있는데, 각각 프로퍼티의 값을 CareAvailableDate 객체와 관계 매핑되어 있는 연관관계를 타고 타고 들어가서 값을 가져오는 방식이었다. 이렇게 되면 생기는 문제는   이런 식으로 지연로딩이 걸린 엔티티들의 값을 조회하..