[Refactoring] 22.08.22. 주문 정보 테이블에 주문에 대한 리뷰의 유무 정보는 필요한가? (feat. reviewExist)

주문 정보 테이블에 주문에 대한 리뷰의 유무 정보는 필요한가?

DB에 주문 정보를 담는 table에는 해당 주문에 대한 리뷰의 존재 유무를 담을 수 있는 column이 만들어져 있다. 하지만 해당 column이 굳이 존재해야하는가에 대한 의문이 들었다. 이는 얼마 전의 작업에서도 마찬가지였다.^[각주:1] 따라서 이에 대한 고찰을 한 뒤, 수정이 필요하다면 어떤 식으로 수정할 것인지를 정리해보고자 한다.

 

코드 뜯어보기

OrderServiceImple.java

 위 내용은 주문 정보를 가져오는 OrderService의 getList method이다. Paging 처리를 위한 작업이 함께 되어있어서 조금 정신없지만 기존 logic부터 살펴보면 다음과 같다.

• OrderDto에 접속한 계정의 email 정보를 담아 계정으로 주문한 내역을 가져온다.
• 각 주문 내역에 대해, 내역의 매장 번호를 이용해서 리뷰 table에서 해당 매장의 평균 별점을 계산해서 가져온다.
• 각 주문 내역에 대해, 내역의 주문 번호를 이용해서 리뷰의 존재 유무를 파악해서 존재한다면 해당 매장에 대한 계정의 별점 정보를 가져온다.
• 각 주문 내역에 대해, 내역의 매장 번호를 이용해서 매장 정보를 조회하여 현재 접속한 email과의 일치 여부를 확인하여 매장을 이용한 사람이 매장 관리자인지 아닌지 여부를 구분한다.

 

 우선 위 logic은 마이 페이지로의 이동 시, 접속한 계정으로 주문한 내역을 불러오기 위해 사용된다. 따라서 접속한 계정의 email 정보를 이용해서 주문 내역을 조회하는 것에는 문제가 없다.

 

 하지만 그 다음, 각 주문 내역에 대해서 내역의 매장 번호를 이용해서 해당 매장의 평균 별점을 계산해서 가져오는 과정에는 문제가 있다. 이전에 매장 상세 정보 페이지에 대한 refactoring을 진행할 때, DB의 매장 정보 table의 구조를 바꾸면서 새로 평균 별점 정보를 담는 avgStar와 전체 review의 개수를 담는 reviewCount column을 추가해주었다. ^[각주:2] 따라서 리뷰 table에서 평균 별점을 계산해서 가져오는 과정은 필요가 없어졌다.

 

 따라서 매장 번호에 대한 리뷰의 별점 data로 평균 별점을 가져오는 대신, 매장 번호로 매장 data를 가져와서 그 평균 별점 data를 가져오는 방식으로 수정했다. 어차피 DB를 한 번 조회한다는 점은 동일하지만, 기존에 여러 row를 조회한 것과는 달리 하나의 row 만을 조회하고 추가적인 계산 과정이 없다는 점이 달라졌다.

 

 다음은 해당 주문 번호로 접속한 계정이 리뷰 때 작성한 별점 정보를 가져오는 logic이다. 여기에서는 리뷰를 작성했을 때, 주문 table의 reviewExist column에 "YES"를 넣어 해당 주문에 대한 리뷰의 존재 여부를 저장해주는 방식을 사용했다. 만약 이렇게 column으로 저장하지 않는다면, 주문 내역의 주문 번호로 리뷰를 불러올 수 있는지의 여부가 리뷰가 존재하는지의 여부가 되며 별점을 그 star의 data로 갱신하면 된다. 물론 이때는 추가적으로 dto의 reviewExist 항목을 채워주어야 한다.

 

 생긴 것을 보니 주문 table에 reviewExist 에 리뷰가 존재하는지 여부를 넣어주는 편이 더 나을 것 같다는 생각이 든다. 그래서 수정한 사항을 모두 원래대로 돌렸으며, 각 list에 부여한 리뷰의 별점 정보를 넣는 것을 if문 밖으로 옮겨주었다. (사실 옮겨주지 않아도 아무 내용이 들어가지 않으면 어차피 0이 들어가게 되어있지만, 그냥 꺼내주었다.)

 

 마지막으로 주문자의 정보가 해당 매장 관리자인 경우를 구분하는 부분이다. 관리자의 경우는 리뷰를 작성한다는 것이 맞지 않기 때문에, 해당 리뷰 작성 element를 disabled 로 설정해주기 위한 logic이다. 위쪽에 이미 매장 정보를 받아온 부분이 있어서 중복되는 내용을 지워주었다.

 필자는 처음에 굳이 관리자가 주문 내역을 남겨서 이렇게 구분해야만 하는지 이해할 수 없었고, 지금도 동일하다. 해당 내용은 지금은 그대로 두지만, 이 project를 다른 tool로 만들 때는 가차없이 없애고 싶은 부분이라고 기록만 해두겠다.

 

이로써 OrderService에서도 Http 의존성을 제거하면서 logic을 한 번씩 모두 살펴보았다. 

1. [Refactoring] 22.08.04. 마이 페이지 (정보 수정, 탈퇴) (tistory.com) [본문으로]
2. [Refactoring] 22.08.19. 매장 상세 정보 페이지 (tistory.com) [본문으로]