[Refactoring] 22.08.21. 주문 페이지

주문 페이지

구성

1. 메뉴 선택

• 메뉴의 정보를 확인할 수 있다.
• 메뉴의 수량을 정할 수 있다.
• 수량을 정해 메뉴 카드를 클릭해 우측에 주문 내용을 추가할 수 있다.

2. 주문하기

• 주문하기 버튼을 통해 추가한 주문 내용에 맞게 주문할 수 있다.

 

 

코드 뜯어보기

OrderController.java

• authOrder - getStoreData / getMenuList / getSeat

 자리 선택 후, 주문 페이지로의 이동 요청에 대한 controller의 method이다. 이제껏 계속 바꿔왔으나 아직 남아있는 StoreService의 getMyStore_num method를 getStoreData로 바꿔주었다. 또한 현재 상태로는 MenuService의 getMenuList 출력하도록 하지 않았으므로 이를 ModelAndView 객체에 넣어주었다. 또한 SeatDto 객체를 통해 받을 수 있는 항목을 굳이 Request 객체를 사용한 부분을 지워주고, 대신 OrderDto로 받아 전달하도록 했다. 마지막으로 ModelAndView와 Request 객체로 따로 request scope에 담은 data를 ModelAndView 로만 전달하도록 바꿔주었다.

 각 service logic은 단순히 data를 가져오는 것이므로 하나의 serivce로 만들지 않았으며, 각 service logic은 이전의 refactoring 작업을 통해 한 번씩 만졌던 친구들이기에 또다시 살피지는 않았다. 의도한 바로는 카테고리 별로 메뉴를 확인할 수 있도록 했는데, 팀원이 이를 구현하지 않은 이유는 시간 때문인 것으로 추정한다. 추후 이 프로젝트를 다시 만지게 될 때, 천천히 가지고 놀면 좋겠다.

 

• insert - orderInsert

 주문 요청 시 주문 내용을 추가하는 요청에 대한 controller의 method이다. 일단 보기에는 service 안쪽에서 Map 객체를 다루는 것으로 끝낼 것 같지만, 사실은 그렇지 않다.

 

 Front에서는 위와 같이 두 번에 걸쳐서 요청이 진행되는 것으로 되어있다. 주문 내역을 DB에 저장하는 과정, 해당 주문에 대한 자리 정보를 DB에서 수정하는 과정으로 나누어져있다. 이는 front 쪽에서 주문 목록에 추가한 내용들을 각각 DB에 넣고, 해당 주문들을 각각 insert 요청으로 DB에 넣어주는 logic이기 때문이다. 하지만 이런 식으로 작성하면 logic 사이에 문제가 발생했을 시 이미 변경된 DB의 내용을 원래대로 돌리지는 못하게 된다. 이는 이전 게시물에서도 잠시 언급했다.^[각주:1]

 

 이 두 요청을 하나로 통일하는 과정에서 상당한 시간을 소요했다. 많은 시행착오와 에러 메시지를 마주한 후에야 겨우 기능이라도 구현할 수 있었다. 이제 천천히 어떻게 수정했는지 설명하고자 한다.

 

 우선 import한 js의 logic을 사용하지 않고, 직접 fetch의 내용을 작성했다. 아무래도 백엔드 쪽을 중심으로 refactoring을 하다가 타인이 작성한 front의 코드를 바꾸자고 하니 어려운 과정이었다. 그렇다고 잘 뜯어고쳤다고는 말할 수 없고, 기존에 있는 내용을 최대한 유지한 채로 작성했다.

 변동사항은 다음과 같다.

1. 한 번의 요청으로 주문 table에 data를 추가하는 것과 자리 table의 data를 변경하는 것을 동시에 하기 위해서는 두 가지 내용을 한 번에 보내야 한다. 따라서 이들을 JSON의 형식으로 보내기로 했다. 보낸 후 JSON data를 ObjectMapper 객체를 이용해서 OrderDto와 SeatDto에 각각 mapping 하는 것이 최종 목표였다.
2. 주문 정보와 자리 변동 정보가 모두 array의 형태로 되어 있어서 해당 array를 그대로 넣어준 것이 아니라 필요한 내용만을 object 형태로 담아 보냈다. 이때, 주문 정보와 자리 변동 정보를 따로 object인 {orderData, objSeat} 의 꼴로 보내는 방법과, 그냥 하나의 {number : data} 의 꼴로 보내되 마지막 항목이 자리 변동 정보의 꼴로 보내는 방법을 사용했다.
3. 정보를 보내고 받는데에 두 가지 방법 모두 가능하나, 공통적으로는 object에서 array를 그대로 넣은 경우 대괄호까지 들어가서 ObjectMapper가 인식하지 못해서 array에 toString( ) 을 사용해주었다.
4. Controller에서 data를 받을 때는 @RequestBody annotation을 붙여 Map type으로 받아서 구분한 뒤, ObjectMapper 객체를 이용해서 OrderDto와 SeatDto로 mapping 하여 dao method를 사용할 수 있도록 했다.

 

 위 세 이미지는 JSON data를 {orderData, objSeat} 꼴로 보내는 경우이다. 각 내용을 Map으로 받아올 때, eclipse에서는 이런 코딩이 위험할 수 있다며 주황색 줄로 경고를 해주는 모습을 보였다. 아마도 전달되는 Map 객체의 type을 제대로 지정해주지 않은 탓이겠다. 이때문에 다음과 같이 {number : data} 의 꼴로 보내는 방식으로도 해봤다.

 

 약간의 logic 차이가 있을 뿐 기능적으로는 둘 다 동작하지만, data가 서로 구분된다는 점에서 전자의 방법에 조금 더 마음이 간다. 다만 주황색 밑줄로 나타나는 eclipse의 경고는 어떤 방식으로 수정해야할지 지금 당장에서는 아이디어가 떠오르지 않아서 아쉽다. 이 주황색 밑줄 때문에 commit은 후자의 내용으로 해두었다.

1. [Refactoring] 22.08.20. 매장 자리 관리 페이지 (tistory.com) [본문으로]