경매 목록 조회 시 쿼리에 존재하는 비즈니스 로직 분리 #739
Conversation
apptie
added
refactor
| for (final Order order : sort) { | ||
| // 다른 정렬 조건에서도 id 기반의 정렬 조건은 무조건 포함되어야 함 | ||
| // 147번째 줄에서 해당 부분을 수행하고 있으므로 이 조건문에서는 과정 생략 | ||
| if (AuctionSortConditionConsts.ID.equals(order.getProperty())) { | ||
| continue ; | ||
| } | ||
|
|
||
| // 신뢰도 기반 정렬 | ||
| if (AuctionSortConditionConsts.RELIABILITY.equals(order.getProperty())) { | ||
| orderSpecifiers.add(auction.seller.reliability.value.desc()); | ||
| continue ; | ||
| } | ||
| // 경매 참여 인원 수 기반 정렬 | ||
| if (AuctionSortConditionConsts.AUCTIONEER_COUNT.equals(order.getProperty())) { | ||
| orderSpecifiers.add(auction.auctioneerCount.desc()); | ||
| continue ; | ||
| } | ||
| // 마감 임박순 기반 정렬 | ||
| // 종료된 경매 목록 조회의 경우 현재 시간과 가장 가까운 마감 시간 상품부터 정렬되어야 함 | ||
| // 그러므로 closingTime.desc()를 정렬 | ||
| if (AuctionSortConditionConsts.CLOSING_TINE.equals(order.getProperty())) { | ||
| orderSpecifiers.add(auction.closingTime.desc()); | ||
| continue ; | ||
| } |
There was a problem hiding this comment.
질문
pr과 상관없는 내용인데 그냥 생각난 김에 이야기해 봅니다.
옛날 미션들을 진행할 때 이런 경우 ID, RELIABILITY 등에 대한 값을 키로, order.getProperty()와 같은 값을 값으로 한 map 형태를 사용했던 기억이 있는데 해당 방식은 별로일까요?
동일한 코드가 4번 반복되어 의견 여쭤봅니다.
There was a problem hiding this comment.
그 방법도 나쁘지 않을 것 같습니다
오히려 지금보다 더 좋아보이네요
|
|
||
| private final JPAQueryFactory queryFactory; | ||
|
|
||
| public Slice<Auction> findAuctionsAllByCondition( | ||
| // 진행 중인 경매 목록 조회 | ||
| public Slice<Auction> findProcessAuctionsAllByCondition( |
There was a problem hiding this comment.
질문
해당 코드로 진행하게 된다면, 진행 중과 종료된 경매 조회의 결과를 합쳐주는 곳은 어디가 될까요?
AuctionRepository 구현체가 될까요 혹은 AuctionService가 될까요?
There was a problem hiding this comment.
이 부분은 밑에 있는 내용과 연관이 있는 것으로 보여서 그 답변으로 대체하겠습니다
There was a problem hiding this comment.
질문
- 현재 코드만 봤을 때는 안드로이드와의 협업이 어디서 필요한지 잘 모르겠는데, 어떤 부분일까요?
- 아직 비즈니스 로직으로 가야 더 좋은 로직에 대해 헷갈리는 부분이 있습니다.
Chatroom과Message에서도 동적 쿼리가 몇 개 있었던 걸로 기억하는데, 이는 필터링을 위해 있는 것이기에 괜찮은 것인지 궁금합니다.
There was a problem hiding this comment.
현재 코드만 봤을 때는 안드로이드와의 협업이 어디서 필요한지 잘 모르겠는데, 어떤 부분일까요?
이 방식은 최종적으로 경매 목록 조회 api를 진행중인 경매 목록 조회 api와 종료된 경매 목록 조회 api로 분리한 것과 동일하다고 보시면 됩니다
그래서 결과를 합쳐주는 부분은 백엔드에서는 존재하지 않고 안드로이드(클라이언트)에 존재하게 될 것 같습니다
예를 들어 진행중인 경매 목록 조회로 쭉 요청을 하다가 isLast가 false로 응답이 오게 되면 그걸 트리거로 종료된 경매 목록 조회 api를 호출하는 그런 식입니다
이런 부분으로 인해 안드로이드와의 협업이 필요하며, 백엔드에서는 결과를 합쳐주는 구간이 없다고 보시면 될 것 같습니다
억지로 한다면 Service에서 처리해줄 것 같습니다만 로직이 복잡해질 것 같습니다
Chatroom과 Message에서도 동적 쿼리가 몇 개 있었던 걸로 기억하는데, 이는 필터링을 위해 있는 것이기에 괜찮은 것인지 궁금합니다.
제가 봤을 때는 지금 상황과 동일한 경우는 없는 것 같습니다
그래서 어떤 메서드를 말씀해주시는건지 잘 모르겠습니다
📄 작업 내용 요약
현재 경매 목록 조회 시 경매 상태가 종료(FAILURE, SUCCESS)인 경매와 진행 중(UNBIDDEN, ONGOING)인 경매를 하나의 쿼리로 조회 중입니다
이 과정에서 분기 처리를 통한 정렬의 우선순위를 부여해야하기 때문에 case when을 사용하고 있습니다
이는 쿼리에서 비즈니스 로직을 수행하고 있어 문제가 생길 수 있는 부분이라고 생각합니다
그래서 이를 리펙토링해야한다고 생각하고, 관련해 간단하게 수도 코드를 작성했습니다
🙋🏻 리뷰 시 주의 깊게 확인해야 하는 코드
설명을 위해 주석 + 나머지 로직을 모두 지워서 테스트도 깨지고 실행도 안되는 상황입니다
그냥 이런 식으로 진행되는구나라고 봐주시면 될 것 같습니다
관련해 자세한 내용은 디스커션을 참고해주시면 될 것 같습니다
📎 Issue 번호