Skip to content

Conversation

@gitseoyeon
Copy link
Member

Summary

Key Changes

  • reservation id 값을 모두 불러와서 같은 날짜의 예약 데이터가 분리 되어 나오는 문제를 해결했습니다.
  • reservationRepository의 findBoothReservationByLinkedBoothId 메소드를 native query로 변경해 date으로 group by 작업을 했습니다.

Testing

수정 전
image

수정 후
image
image

To Reviewers

  • 관리자 시점에서 반환 하는 response 데이터 값과 일반 사용자 시점에서 반환하는 데이터 값의 차이는 예약자 정보 반환 여부 입니다. 현재는 두개 모두 BoothReservationDetailDto라는 동일한 dto를 사용중에 있어 일반 사용자 시점에서 데이터를 볼 때도 예약자 정보가 보이고 있습니다. 그래서 차라리 dto를 따로 분리해서 작업하는게 나을지에 대한 고민이 있어 의견을 여쭤보고 싶습니다!
  • 다른 의견이나 질문 있으시면 리뷰 남겨주세요!

@gitseoyeon gitseoyeon added the refactor 코드를 개선합니다. label Oct 25, 2024
@gitseoyeon gitseoyeon self-assigned this Oct 25, 2024
@muncool39 muncool39 self-requested a review October 28, 2024 07:13
Copy link
Member

@muncool39 muncool39 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

확인했습니다! 수고하셨습니다 😃
하나 궁금한 건 현재 수정된 내용은 같은 날짜 + 하위 시간이 묶여서 나가게 되는데, 같은 서비스를 묶어서 보내려면 서비스 명으로 먼저 그룹을 묶어야 될 것 같습니다! 아래는 예시입니다!

{
reservations : [
  {
    "id" :
    "name" : 
    "price" :
    "dates" : [
        {
            "date_id": 
            "date": 
            "times" : [
                {
                    "time_id": 
                    "time":
                },
	    ]
	},
    . . 
    ]
. . .
  }
]
}

dto 관련 의견 주신 부분은 dto는 동일하게 사용하고 응답 객체를 나눠서 매핑을 다르게 하는 방법을 사용하면 될 것 같습니다! 😃

@gitseoyeon
Copy link
Member Author

의견 주셔서 감사합니다!
말씀하신 내용에 맞게 최대한 구현을 시도해보았습니다.

먼저 날짜와 시간을 묶어서 응답하게 하는 건에 대해서는 처음에 개발할 때는 묶여지는 id마다 날짜별로 그룹화 되어 있어 하나의 날짜에 시간들을 나열하고 또 날짜 다른 날짜의 시간들을 그룹화해서 리스트에 추가하는 형식으로 구현했기 때문에 따로 날짜를 다시 리스트화 시키지 않아도 된다 생각했었습니다.
하지만 말씀하신것처럼 dates라는 리스트를 하나 만들고 그 안에 날짜와 시간 리스트를 넣는 것도 시각적으로 더 명확하게 보이는 것 같아서 수정을 진행했습니다.
image
image
위의 사진이 다시 수정한 후 응답되는 값들입니다. 하나의 날짜와 그에 맞는 시간들의 리스트를 리스트화 시킨 것이기 때문에 dates 대신 reserveInfo 라는 리스트를 만들었습니다.
reserveInfo는 BoothReservationDateDto라는 새로운 클래스를 만들어서 이를 리스트화 시킨 필드 입니다.
BoothReservationDateDto에서는 날짜와 이에 매핑되는 BoothReservationDetailDto의 리스트들을 담고 있습니다.

두번째 applyUser 응답건에 대해서는 현재 BoothReservationDateDto라는 새로운 클래스를 만들게 되면서 BoothReserveResponse와 BoothReserveManageResponse 가 공통으로 사용되고 있습니다. 따라서 앞서 말씀해주신 것 처럼 응답 객체를 나눠서 매핑을 다르게 하는 방법을 사용하긴 했지만 살짝의 한계가 있어 applyUser 필드가 반환 되긴 하지만 null 값으로 처리해 데이터가 응답되지 않게 했습니다.
이에 대해서는 더 고민해보고 수정해보는게 좋을 것 같습니다.

추가로 의견이나 질문 있으시면 말씀해주세요!

Copy link
Member

@muncool39 muncool39 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

확인했습니다! 날짜랑 시간이 묶여서 보기 좋아진 것 같아요!
같은 서비스끼리 묶는 것은 지금 시점에서 어려울 수 있으니 일단 이렇게 진행해도 좋을 것 같네요 수고하셨습니다! 😃

applyUser 필드에 관련해서 @JsonInclude(JsonInclude.Include.NON_NULL) 어노테이션을 사용해 보는 것은 어떨까요? 값이 null인 경우 응답에 해당 필드를 보이지 않게 할 수 있어서 현재 구현하신 방법이랑 잘 맞을 것 같습니다!

@gitseoyeon
Copy link
Member Author

말씀해주신 applyUser에 어노테이션을 적용해보았습니다! 덕분에 새로운 어노테이션을 배워가네요 👍🏻
적용해보니 다음과 같이 일반 유저가 조회시 applyUser가 안나오는 것을 확인했습니다!
image

Copy link
Member

@muncool39 muncool39 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

수정 확인했습니다! 수고하셨습니다 ! 👍

@gitseoyeon gitseoyeon merged commit 1b711fe into dev Nov 3, 2024
3 checks passed
@gitseoyeon gitseoyeon deleted the refactor/#290 branch November 3, 2024 12:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

refactor 코드를 개선합니다.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[REFACTOR] 부스 예약 조회 개선

3 participants