[Refactoring] 22.08.19. 매장 상세 정보 페이지

매장 상세 정보 페이지

구성

1. 매장 정보 확인

• 매장의 이름과 로고를 가장 상단에서 볼 수 있다.
• 매장을 살펴볼 수 있는 대표 이미지를 볼 수 있다.
• 매장의 별점 평균, 태그, 주소, 영업 시간, 남은 자리에 대한 정보를 알 수 있다.

2. 매장 메뉴 확인

• 하단에서 매장에서 구매할 수 있는 메뉴의 정보를 알 수 있다.
• 만약 해당 매장 관리자가 베스트 메뉴를 등록해두었다면 함께 볼 수 있다.

3. 매장 리뷰 확인

• 사용자가 매장에 등록한 리뷰를 볼 수 있다.
• 말 그대로 볼 수만 있으며, 매장 관리자의 답글도 확인할 수 있다.

4. 주문 요청

• 주문 요청을 위한 자리 선택 modal을 띄우는 버튼이 존재한다.

 

코드 뜯어보기

StoreController.java

• goStoreDetail - getStoreData / getMenuList / getReviewList / getSeat

 매장 상세 페이지로 이동 요청을 처리하는 controller의 method이다. 막상 열어봤을 때 원하는대로 출력되고 있지는 않았는데, 메뉴 출력에 문제가 있는 것으로 보아 최초 매장 관련 tag와 메뉴 category 에서 사용된 logic 때문인 것으로 추정된다. 해당 controller와 service에서의 logic은 모두 고쳤으나, 아직 StoreService의 getMyStore_num method가 남아있다. Http 의존성을 제거하면서 logic을 수정해보겠다.

 총 4개의 service logic이 사용되었으나, 모두 DB의 data를 불러오는 용도이므로 이들을 하나로 합쳐주지는 않겠다.

 

 getMyStore_num service logic의 사용에는 의문이 든다. 과연 매장 관리 페이지에서 불러오는 매장의 정보를 위해 굳이 접속한 email을 확인해야하는가의 여부이다. 일단 번호로만 매장의 정보를 불러오고, 해당 data의 email 주소와 다르면 logic을 수행하지 않도록 하는 방안을 사용해도 괜찮지 않을까? 

 이 생각이 들어서 먼저 게시글을 작성했고, 일단은 dao method만을 통일해주었다.^[각주:1]

 

 마찬가지 이유로 메뉴의 List를 불러오는 method도 하나로 통일했다.

 

 다시 goStoreDetail method로 돌아오자. 먼저 getMyStore_num 이다. 이렇게 dao method를 통일해주었다면, 기존에 tag 정보와 category 정보, 매장 정보를 담는 service logic은 필요가 없어진다. 단순히 매장 정보를 받아오는 것으로 service logic을 단순화 했고, 이를 controller에서 getter method로 골라 담아 ModelAndView 객체에 담아주었다.

 이어서 getMenuList method도 return 된 메뉴의 List를 바로 ModelAndView 객체에 담아주었다.

 

 리뷰 List를 가져오는 service logic을 살펴보겠다. 전달받은 dto에는 DB에 저장된 매장의 number data가 담겨있는데, 이를 사용해서 DB로부터 해당 number에 대한 review List를 가져오고, 그것이 null인지 아닌지에 따라 나누었다. Null이 아닌 경우 리뷰의 DB number를 활용하여 다시 해당 review의 targetNum, 즉 댓글인지 대댓글인지의 여부를 확인해서 대댓글의 존재 여부를 dto에 담는 logic이다. 하지만 이 과정에서 다시 DB에 대댓글인지 여부를 확인할 필요가 없다. 해당 ReviewDto에 담긴 targetNum data의 여부만을 확인하면 되는 것이다. 따라서 이 dao method와 Mapper의 관련 query 문을 지워주면서, 바로 targetNum에 대한 조회를 통해 dto에 그 존재 여부를 구분하였다. Dao method 자체는 나중에 사용하므로 지워주지 않았다.

 이어서 DB에서 가져온 review의 전체 List에 대한 길이 값이다. 이또한 사실 DB의 query 문을 통할 필요가 없으며 동시에 변수로 만들어 request scope에 담에 front로 보낼 필요가 없다. 그냥 List를 보내고, 그 size를 체크하면 되는 부분이다. 따라서 totalReviewCount 변수를 지우고, 해당 dao method와 Mapper에서의 query문을 지워주었다.

 

 dto 라는 변수에는 storeNum field에 DB에 저장된 매장의 번호가 있다. 이를 활용해서 매장의 평균 별점 값을 따로 계산해 얻어오는 dao method와 query문을 작성했었다. 만약 매장 table에 평균 별점, 전체 review의 수를 column으로 만들어 data를 저장하도록 했다면 이런 번거로운 작업은 하지 않아도 됐을 것 같다. 또한 나중에는 즉각적으로 별점의 값을 바꾸도록 한 부분이 나올텐데, 역시 column이 따로 존재했다면 이 getReviewList logic에서는 리뷰의 List 정보만을 간단히 return하는 형태가 되었을 것이다. 따라서 이참에 매장 table에서 지우려고 했던 imageCheck column을 없애면서 avgStar 와 reviewCount 에 대한 항목을 넣어주었다. 그에 맞게 storeDetail.jsp에서 매장 정보가 들어있는 dto를 통해 값을 받도록 수정했다. 그렇게 getReviewList service logic에서는 리뷰의 List 정보만을 온전히 return할 수 있게 되었다.

 

 마지막인 SeatService의 getSeat method이다. HttpRequest 객체로 매장의 number data를 가져왔지만, 전혀 그럴 필요가 없다. Controller에서 넘겨받은 StoreDto에 이미 number 정보가 있기 때문이다. 하지만 SeatDto는 장점이 하나 더 있다. 매장 table과 자리 table의 DB number는 동일하도록 logic이 짜여있다. 따라서 그냥 SeatDto를 사용해서 자리 정보를 얻어오면 되고, 동시에 Http 의존성을 없애면서 ModelAndView 객체를 사용하지 않도록 바꾸면 한 service logic은 한 줄로 변한다. 하지만 이렇게 바꾸게 되면, 기존에 이 logic을 사용하고 있던 SeatController와 OrderController에서 난리가 나게 된다. 때문에 해당 곳에서 동일한 방식으로 일단 수정해주었다.

 

 이로써 StoreController의 goStoreDetail method까지 수정을 마쳤다. 여러 service가 섞여있고, 그 service logic이 이곳이 아닌 다른 곳에서도 사용되는 바람에 이곳에 대해 살펴보는 것이 많이 지체되었다. 사실 계획대로라면 Controller 하나씩 먼저 살펴봤었어야하는데, 필자의 불찰인 것 같다.

 

 다음 게시물에서는 주문 관련 요청 처리를 하는 OrderController를 살펴보게 될 것이다.

 

1. [Refactoring] 22.08.18. StoreService의 getMyStore Logic에 대하여 (feat. Dao, Mapper) (tistory.com) [본문으로]