[Refactoring] 22.08.27. 매장 리뷰 관리 페이지

매장 리뷰 관리 페이지

구성

1. 리뷰 확인하기

• 매장을 방문해 주문한 유저의 리뷰를 확인할 수 있다.
• 매장 관리자가 유저의 리뷰에 댓글을 남길 수 있다.
• 남긴 댓글은 수정 및 취소가 가능하다.

 

코드 뜯어보기

StoreController.java

• storeReview - getReviewList

 매장 리뷰 관리 페이지로의 이동 요청을 처리하는 controller의 method이다. ReviewService의 getReviewList는 지난 게시글에서 다룬 service method이다.^[각주:1] 해당 게시글에서 getReviewList를 Map 으로 return 하고 있어서 화면이 제대로 출력되지 않고 있다.

 우선 StoreDto로 number data를 받고 있으니, 굳이 필요 없는 HttpServletRequest 객체를 전달받지 않도록 하고, 그것을 사용하는 부분을 지워주었다. 그리고 Request 객체를 통해 request scope에 data를 담던 것을 ModelAndView 객체로 바꿔주었다. 그리고 getReviewList service method로 넘어오는 것이 Map 객체이므로, 그 key로 연결시켜주었다.

 그리고 이 method를 ReviewController로 옮겨주었다.

 

ReviewController.java

• getMyReview - getMyReview

 매장 관리 페이지에서 매장 관리자가 유저가 남긴 리뷰에 댓글이 존재하는지 여부를 확인하는 요청에 대한 controller의 method이다. Service logic을 보니 HttpServletRequest 객체를 전혀 사용하고 있지 않아서 지워주었다.

 

 두 번이나 DB에 data를 요청하는 것을 한 번으로 바꾸고, ReviewDto도 variable을 갱신하는 것으로 바꿔주었으며, 분기의 과정도 variable을 사용하지 않는 쪽으로 바꿔주었다.

 

 사실 이 controller와 service logic은 댓글이 많아질 경우 모든 내용을 loading하지 않고, 각각을 따로 loading하기 위한 부분이었다. 하지만 단순히 페이징 처리를 했다면 작성하지 않아도 될 부분이었다고 생각한다.

 

• addReview - addReview

 리뷰를 추가하는 부분의 service logic에서는 매장 관리자의 리뷰에 대한 댓글을 작성하는 부분이 고려되지 않았다고 언급했었다. 그에 대한 처리를 해주려고 한다.

 

 리뷰를 추가하는 logic을 유저와 매장 관리자가 구분될 수 있도록 해야한다.

 

 그래서 경우에 맞게 동작할 수 있도록 매장 관리자의 여부에 따라 분기한 곳의 안쪽으로 logic을 구분해주었다. 매장 관리자의 경우는 리뷰의 수나 평균 별점에 대한 logic, 리뷰의 존재 여부를 update하는 logic이 필요없다.

 

 이렇게 수정하고 test하는 과정에서 getReviewList의 logic에도 매장 관리자의 댓글 관련하여 올바르게 출력되지 않는 문제를 발견하고 해당 logic을 수정했다.

 

• updateReview - updateReview

수정 사항에는 매장 이용자가 작성할 때와 매장 관리자가 작성할 때를 굳이 구분할 이유가 없다. 매장 이용자의 경우는 별점이나 이미지 정보가 없을 뿐이다. 동작은 동일하다.

 

• deleteOwnerReview - deleteReview_owner

 매장 이용자의 리뷰에 매장 관리자가 작성한 댓글을 지우는 요청에 대한 controller의 method이다. 왜 매장 이용자의 것과 구분한 것인지, 구분하지 않아도 된다면 어떻게 바꿀 수 있을 것인지 고민해볼 것이다. 구분해야 한다면 Map 객체를 다루는 것도 service 안쪽으로 넣어주려고 한다.

 

 Service logic이 꽤나 단순하다. 때문에 구분한 이유부터 살펴보아야 겠다.

 

 매장 사용자의 리뷰는 주문 번호를 통해 지우고 있다. 리뷰는 주문 번호 당 하나만을 남길 수 있으므로, 주문 번호를 통해 지우게 되면 매장 관리자의 댓글까지 한 번에 지울 수 있다. 리뷰가 없는데, 관리자의 댓글만 존재하면 이상해진다.

 그래서 매장 관리자의 리뷰는 해당 리뷰의 target number data를 이용해서 지운다. 하지만 두 query 문을 하나로 합친다면 dao method도, controller의 method도 나눌 필요가 없다. 물론 그럴 경우에는 리뷰를 삭제하는 logic에 매장의 리뷰 수와 평균 별점 내용에 대한 내용이

있으므로 리뷰를 추가하는 logic과 마찬가지로 매장 이용자와 관리자의 경우로 나눠야 한다.

 

 그렇다면 두 logic을 하나로 꼭 합쳐야할까? 하나로 합치기 위해서는 접속한 email 정보를 받아와야 하고, 해당 email과 매장 관리자의 email 정보를 비교해야 한다. 또한 Front에서 DB의 매장 번호의 정보를 받는다면 DB에 한 번 더 data를 조회해서 비교가 가능해진다. 기존에 리뷰를 삭제하던 두 logic에서 email 정보를 요구하지 않았으므로, 이번에 그 정보를 사용하는 logic으로 바꾸는 것이 나아보인다.

 

 이렇게 되면 기존에 나누어져 있던 logic과 dao method, query문은 삭제해도 된다.

 

 

 이렇게 ReviewService까지 모든 logic에서 Http 의존성을 없애면서 각각의 수정 과정을 거쳤다.

1. [Refactoring] 22.08.26. 마이 페이지 (리뷰 작성, 수정, 삭제, 확인) (tistory.com) [본문으로]