[Refactoring] 22.08.17. 매장 메뉴 관리 페이지

매장 메뉴 관리 페이지

구성

1. 메뉴 카테고리 추가 / 삭제

• 메뉴의 카테고리를 추가하고 삭제할 수 있다.
• 카테고리를 추가하면 메뉴 추가 시, 카테고리를 설정할 수 있다.
• 카테고리를 클릭하면 해당 카테고리로 등록한 메뉴만을 살펴볼 수 있다.

2. 메뉴 추가 / 삭제

• 메뉴를 추가하고 삭제할 수 있다.
• 반드시 카테고리를 추가해야 메뉴 정보를 등록할 수 있다.
• 메뉴의 이미지, 상품명, 가격, 구성, 카테고리를 설정해서 추가할 수 있다.

3. 대표 메뉴 등록

• 메뉴를 등록한 후, 메뉴 항목의 별표시를 누르면 대표 메뉴로 등록된다.
• 대표 메뉴로 등록되면 매장 상세 정보 페이지에서 따로 구분되어 보이게 된다.

 

코드 뜯어보기

 우선 작업을 시작하기에 앞서, StoreController에 분할되어 있는 메뉴 카테고리 추가/삭제 관련 method를 MenuController로 옮겨주었다. 그 과정에서 Service와 Dao, Mapper의 내용이 Store에서 Menu 항목으로 이동되었다.

MenuController.java

• getList

 매장 메뉴 관리 페이지로 이동하는 controller의 method이다. 두 개의 service logic method가 있으나, 단순히 DB에서 data를 가져오는 logic이므로 하나의 service logic으로 만들지는 않는다.

 

우선 MenuService의 getMenuList 를 보면 상당히 혼미하다. 찬찬히 뜯어보도록 하겠다.

 

 메뉴를 구분하는 카테고리에 대한 전체 정보는 매장 정보 DB에서 관리하고 있다. 이후에 카테고리를 추가/삭제 하는 logic에서도 살펴볼 것이지만, 매장 정보 관리할 때 tag에 대한 logic과 동일하게 되어 있다. 메뉴 DB에도 카테고리에 대한 column이 있기는 하나 해당 메뉴가 어떤 카테고리에 포함되는지의 여부만을 가지고 있다.

 결과적으로 메뉴 data를 담은 List 정보를 front에 전해줘야하는 것은 당연하고, 매장에 대한 정보를 넘기는 이유는 front에서 DB에 등록된 매장의 번호를 필요로하기 때문이다. 해당 번호를 element에 적절히 숨겨넣어, 다른 동작에 대한 요청에 번호를 넘겨받도록 해두었던 것이다. 이때 매장의 이름도 받도록 되어있지만, 해당 logic은 매장 번호만 받아도 정상적으로 수행될 수 있다.  DB를 만들 때, 메뉴 table에서 매장 이름에 대한 column은 애초에 만들지 않았어야 한다. 이때문에 매장 정보를 update 할 때, 메뉴 table의 매장 이름까지 수정하도록 하는 logic이 되어버려서, 더더욱 만들지 않았어야 하는 것이 맞다. 때문에 이와 관련해서 manageMenu.jsp 에서 경로 요청에 매장 이름이 포함된 부분을 제거해주었다.

 

 또한 매장의 메뉴 List를 가져오는 dao method의 query문에서는 접속중인 email 정보와 매장 정보 뿐만 아니라 카테고리 정보를 불러온다. 이때 사용되는 카테고리 정보는 요청 경로의 query를 통해 얻어지며, 해당 카테고리의 메뉴 data만을 얻어오는 것이 목적이다. 그래서 category 정보가 전달되지 않는 경우와 전달되는 경우에 실행되는 sql문을 구분한 것이다. 위 이미지가 바로 그 sql문을 수정한 것이다. 당시 구분했던 이유는 null check가 되지 않았기때문인데, 이번에도 동일하게 오류가 발생해서 상당히 고생을 했다. 그 이유는 test 구문에 중괄호 { } 를 씌웠기 때문인데, 여기에 중괄호를 사용하지 않도록 주의해야겠다. 이렇게 query 문의 오류를 해결하면서 if문으로 구분했던 logic을 하나의 dao method를 사용하는 것으로 통일했고, 나눴던 dao method와 query문을 모두 지워주었다.

 이를 통해 service logic으로 return 된 메뉴의 List를 그대로 ModelAndView 객체에 넣어 front로 전달하도록 했고, front에서 사용될 매장의 번호를 그대로 전달하는 부분은 key 값을 수정하면서 manageMenu.jsp 에서의 data를 받을 부분도 수정해주었다.

 

 getList 에 사용된 또다른 service logic method인 StoreService의 getMyStore_num 은 tagList와 categoryList를 request scope에 전달하는 방식으로, 아직 Http 의존성 제거를 해주지 않은 service method이다. StoreController에 하나, OrderController에 하나가 있어 총 3번 사용되고 있다.

 이곳에서는 StoreService의 getMyStore_num method 가 아닌 getMyStore method를 사용해서, 해당 매장 정보의 category data를 ModelAndView 객체에 넣어 front로 전달하는 방식으로 수정했다. 이는 순전히 의도한 것이 아니라 우연히 수정한 것이 완성된 상태가 되었다. getMyStore_num method에서는 tag의 경우와 마찬가지로 logic이 짜여있어서 String을 List로 바꿔서 data를 만들었는데, 그것을 생각하지 못하고 단순히 쉼표로만 구분되어 있는 category의 data를 front에 전달해준 것을 알아서 구분하고 있었다. 쉼표로 구분되어 있는 것이라도 front에서 foreach를 통해 구분이 가능하다는 강사님의 말씀이 잠시 스쳐지나갔다.

 

 

• addCategory / deleteCategory

 매장 메뉴를 등록하기 위한 카테고리를 추가하는 controller의 method이다.

 사용된 service logic은 이전 tag 관련된 logic과 아주 동일하다. 따라서 이전 tag logic을 수정한 것과 마찬가지로 수정해주었다.^[각주:1] 조금 더 수정한 점이 있다면 이는 매장을 관리하는 곳이니 관리하는 권한이 있어야한다고 생각해서 email data까지 받는 dao method인 getMyStore로 고쳐주었다. 기억상 getMyStore_num 이라는 logic이 따로 있는 이유는 기존에 매장 번호를 받아가는 요청이 아니라 해당 유저가 관리하는 매장의 번호를 순서대로 1, 2, 3으로 설정했었기 때문인데, 이후에 매장 번호를 받아가고 요청하는 것으로 수정하면서 사실상 getMyStore_num 의 logic은 필요가 없게 되었다. 따라서 최종적으로는 getMyStore_num method를 사용하지 않아서 지우는 것이 목표이다.

 

 deleteCategory 역시 이전 tag 관련 logic과 동일하게 수정해주었다.

 

 

• addMenu

 메뉴를 추가하는 controller의 method이다. Map 객체를 만드는 것을 service 안쪽으로 넣고, Http 의존성을 제거하면서 logic을 살펴보려고 한다.

 

 파일을 저장할 경로를 얻어오기 위해 HttpServletRequest 객체를 사용하고 있다. 이를 service 바깥에서 전달받도록 바꾸었다. 이런 내용이 반복적으로 나오고 있지만, 만약 이를 다른 server로 올린다고 생각하면 이를 바꿔주어야 할 것이다. Service logic의 앞부분에는 StoreDto를 통해 number data를 setting해서 data를 가져오는 이상한 내용이 있다. 이는 처음에 매장의 number 정보를 사용해서 만든 것이 아니라 존재하는 것으로, 이제는 쓸모가 없어진 부분이기에  지워주었다. 그리고 성공 여부를 달리해서 Map 객체에 담아 return 하는 것을 service 쪽으로 들여왔다. 더하여 MenuMapper 의 query 문에서 storeName column에 insert 하는 내용을 지워주었다.

 

 사실 이것으로 끝이긴 하나, 카테고리를 추가/삭제할 때 email 정보를 사용했던 것처럼 메뉴도 마찬가지이어야 한다는 생각이 불쑥 들었다. Logic 내에서는 email 정보가 굳이 필요한 것은 아니지만 말이다. 만약 접속한 email 정보를 사용해야한다면 어떻게 바꿔줄 수 있을까? 메뉴 추가 요청으로부터 넘겨받은 dto의 매장 번호와 session scope의 email 정보를 이용해서 매장 정보를 불러올 수 있을 때 logic을 수행하도록 하면 될 것 같다.

 

 작업 자체에서 문제가 생긴 것은 메뉴 table에서 매장의 이름에 대한 column 까지 가지고 있는 것으로, 해당 column은 null 이 아니도록 만들어져서 안쓰고 싶어도 현재 써야하는 상황이다.

 아직 data를 많이 넣은 상황이 아니기때문에 table을 지우고 다시 만들면 된다. Service logic에서 storeName 을 사용하지 않기 위해서 table을 다시 만들었다.

 

 

• deleteMenu

 매장의 메뉴 정보를 삭제하는 controller의 method이다. Map 객체 생성하는 과정을 service 안쪽으로 옮길 것이다.

 

 Service logic은 의외로 간단했다. DB에 저장된 번호 정보를 받아서 삭제하고 있었다. 역시 여기에서도 메뉴 정보를 삭제할 때, 접속한 계정이 관리하는 매장인지 확인할 필요가 있을 것 같다.

 

 메뉴 항목이 사라지면 주문 관리 페이지든 마이 페이지든, 주문 내역을 확인할 때 문제가 생길 것이라는 생각이 든다. 그렇다면 매장 정보를 지우면 관련 메뉴와 주문 등의 정보를 모두 지우는 것처럼, 여기에서도 메뉴 항목이 사라지면 관련 주문 내역을 모두 지워야 할까? 기획상 원하는 방향성이 아니기는 하다. 일단은 그냥 두고 앞으로의 refactoring을 조금 더 지켜보려고 한다.

 

 

• bestOnOff

 매장의 메뉴를 best 로 설정 및 취소하는 controller의 method이다. Map 객체에 담아 return 하는 logic을 service 안쪽으로 넣으면서 Http 의존성을 제거해볼 것이다.

 

 우선 사용하고 있는 email data를 service의 바깥쪽에서 넘겨받는 것으로 바꾸었다. 그리고 사용하지 않는 storeName에 대한 내용을 없애주면서 MenuDto에 받아올 수 있는데도 Request 객체를 사용한 것을 바꿔주었다. 마지막으로 순간 혼동되어 헷갈렸던 것에 대한 주석을 달아주었고, 한 번에 처리할 수도 있었지만 두 단계로 나누어 경우에 따라 다른 값을 Map 객체에 넣어 return 해주었다. 이 과정에서 사용되는 MenuMapper.xml의 query 문에서 storeName에 대한 내용을 지워주었다.

 

 

• updateStore (StoreService)

 이 내용은 메뉴 table에서 storeName 에 대한 column을 없애면서 필요없게 된 MenuMapper.xml의 query 문이다. 따라서 이와 관련된 query문을 지우고, 해당 dao method를 지워주었다. 그리고 해당 dao method를 사용하지 않도록 수정해주었다.

 

 

 이렇게 MenuController에서 사용하는 service logic을 수정하면서 대부분의 MenuService의 logic을 수정했고, Http 의존성을 제거해주었다. 이미지 상으로 하나 남았는데, 해당 service logic은 매장 상세 페이지에서 사용되는 것으로 기억한다. 해당 친구는 매장 상세 페이지를 더 보면서 수정해보려고 한다.

1. [Refactoring] 22.08.15. 매장 정보 관리 페이지 (이어서) (tistory.com) [본문으로]