[Refactoring] 22.08.22. 매장 주문 관리 페이지

매장 주문 관리 페이지

구성

1. 주문 내역 확인

• 매장에 대한 주문 내역을 확인할 수 있다.
  (주문 내역, 주문자, 주문자의 번호, 좌석 정보, 주문 시간)

2. 주문 확인, 취소 확인

• 주문 내용을 확인하고, 주문 취소 내용을 확인처리 할 수 있다.

 

코드 뜯어보기

StoreController.java

• storeOrder - getOrderList

 주문 관리 페이지로의 이동 요청을 처리하기 위한 controller의 method이다. Http 의존성을 제거하고, 필요한 정보를 ModelAndView 객체에 담는 방식으로 수정하려고 한다.

 

 주문 관련 파트는 팀원이 맡았는데,  method 이름과 구성을 보니 팀원이 필자의 코드를 그대로 복사하여 작성한 내용인 것 같다. 왜냐하면 필자의 실수로 만든 dao method와 query문이 동일한 방식으로 사용된 모습을 발견했기 때문이다. 일단 service method의 이름을 수정해주었고, dao method와 query문을 지워주었다. 그리고 해당 logic에서는 paging 처리를 하고 있는데, 아무래도 기존에는 그냥 스크롤로 내용을 보는 것이 아닌 아닌 paging의 목적이 있었던 것 같다.

 

 일단 paging logic은 그대로 둔 채, 나머지 부분을 Map 객체를 통해 controller로 보내주는 방식을 채택했다. 사실 controller에서 넘겨받은 Map 그 자체를 ModelAndView에 담에 front에서 data를 조회할 때, 한 단계만 더 거치도록 하는 것이 controller 부분을 조금 더 깔끔하게 만들 수 있는 방법이긴 하다.

 

 하지만 이렇게 front 부분을 수정하려고 하지 않았던 필자에게 바로 업보가 찾아왔다. Service logic을 바꿔준 것 뿐인데도, 제대로 화면이 출력되고 있지 않았다. 그래서 다음과 같은 문제를 발견했다.

 

 이 사람은 각 성분에 들어갈 data를 페이지가 로딩된 후 요청해서 받아오는 방식으로 코딩했다. 그 이유는 알 수 없으나, 이전에도 이 사람은 이런 방식의 코딩을 많이 했었다. 이쯤 되면 이 방식으로 코딩했을 때, 좋은 점이 있어서 택하지 않았을까하는 생각도 든다.

 오류가 발생한 것은 주문한 사람의 email 정보가 담긴 html elements의 수와 confirm 혹은 cancel 관련 elements의 수가 다를 수 있기 때문이다. 따라서 이 내용을 서로 분할해주는 것으로 단순하게 수정을 완료했다. 하지만 for 문의 중간에서 주문 확인이나 취소 요청에 대해서 주문 번호를 넘기고 있으므로, 주문 확인과 취소 버튼 전체를 for문으로 묶되 두 사항을 하나로 묶기 위해 element에 같은 class 내용을 가진 'reverse-btn'을 활용했다. 사실 필자였다면 javascript 부분을 모두 날리고 직접 element에 data를 전달해서 출력해주었을 것인데, 백엔드 Java를 중심으로 refactoring을 하고 있으므로 이 부분이 마음에 들지 않는다는 점만 체크하고 넘어가려고 한다.

 

 

OrderController.java

• orderMenuDetail - getOrderMenuList

 주문 관리 페이지에서 로딩 시 주문 정보 요청에 대한 controller의 method로, 단순히 data만 받아오고 있어서 따로 건들지 않으려고 한다.

 

• updateState - updateState

 주문 관리 페이지에서 주문 확인 혹은 주문 취소에 대한 주문 table에서의 DB data 수정에 대한 controller의 method이다. 사용하지 않는 HttpServletRequest 객체를 지워주었다.