[우아한명지코스] 고건 Spring Data JPA 4, 5, 6단계 미션 제출합니다.#227
Open
Gopistol wants to merge 14 commits into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
안녕하세요. 먼저 이번 리뷰 일정보다 많이 늦어지게 되어서 죄송합니다 .. 다음 미션은 기한에 맞추어 성실히 제출하겠습니다!!
개발하면서 고민한 사항 정리해보겠습니다.
요구사항에서 주어진 예시를 그대로 수용하기보다, 필요에 따라 타입이나 구조 등을 바꾸었습니다. 예를 들어 TimeId를 문자열로 보내는 예시를 숫자 타입으로 바꾸어 적용했습니다.
findByMember의 책임
/reservations-mine은 예약 확정 목록과 대기 목록을 합쳐서 반환합니다. 이를 ReservationService.findByMember()하나에서 처리했는데, 서비스가 WaitingRepository까지 의존하게 되는 구조입니다. 서비스를 분리할지, 아니면 조회 전용 서비스/파사드를 둘지 고민되었습니다.
대기 순위 계산 방식
예시처럼 Waiting 클래스에 멤버 변수로 rank를 두어 DB에 저장하지 않고,. count 쿼리로 동적 계산하는 방식을 선택했습니다. 대기 취소 발생 시 나머지 순위를 별도로 계산하지 않는 장점이 있다고 생각합니다. 하지만 조회마다 추가 쿼리가 나가게 되는 트레이드오프가 있어 어떤 것이 더욱 효율적인 방식일지 고민했습니다.