[Refactoring] 22.08.20. 매장 자리 관리 페이지

매장 자리 관리 페이지

구성

1. 자리 등록하기

• 자리 배치도를 업로드 할 수 있다.
• 자리 배치도에 맞게 자리를 늘리거나 줄일 수 있다.
• 자리 배치도에 대한 설명을 작성할 수 있다.

2. 자리 설정하기

• 자리의 상태를 이용중 / 이용 가능 / 이용 불가 의 세 가지로 구분할 수 있다.

 

코드 뜯어보기

SeatController.java

• getSeat - getSeat

 매장 자리 관리 페이지 이동 요청을 처리하는 controller의 method이다. 이전 StoreController의 goStoreDetail method에서 사용했던 SeatService의 getSeat logic이 있다. 이전에 Http 의존성은 없앴지만, 나머지 controller의 내용을 손보았다. 이미 controller에서 넘겨받은 SeatDto 객체에는 DB에 저장된 매장의 number data가 들어있다. 따라서 한 번 더 Request 객체를 통해 number data를 받고, 그것을 다시 SeatDto 객체에 number data를 setting 하는 과정을 없앴다.

 

 SeatService의 getSeat method는 아주 간단해졌으므로 따로 건들지 않았다.

 

 

• ajaxSeatUpload - saveSeatImage

 ajax 방식으로 자리에 대한 이미지 파일을 upload하는 controller의 method이다. Http 의존성을 없애면서 수정을 할 것이다.

 

 HttpServletRequest 객체를 service logic 안에서 사용하지 않고, service 바깥의 controller에서 사용해서 그 필요한 path 정보를 받는 것으로 바꿔주었다.

 

 

• updateEmptySeat - updateEmptySeat

 다른 곳에서 사용하지 않으며 요청하지도 않는 줄 알았는데, 주문 시 빈 자리와 사용 중인 자리를 update하기 위한 요청을 처리하는 controller의 method였다.

 

 Map 객체의 생성과 dao method로 query문의 성공 여부에 따라 다르게 return 하도록 수정했다. 하지만 문제는 그것이 아니었다.

 

  SeatController의 이 method가 호출되는 곳은 주문 정보를 insert 하는 경로를 요청한 후, 또다시 자리 정보를 수정하는 경로를 요청한다. 왜 한 번에 처리하지 않고 이런 요청 방식으로 구현했을까? 만약 주문을 추가하는 요청에서는 문제가 없었지만, 자리를 추가하는 과정에서 오류가 발생했을 때 기존 처리를 되돌릴 수 있는 transaction 작업을 해줄 수 없을 것이다. 때문에 위 이미지에서처럼 두 차례에 걸쳐 logic을 나누면 안된다. 이에 대한 수정은 OrderController를 다루는 게시물에서 다루려고 한다.

 

 

• updateSeat - updateSeat

매장 자리 정보를 수정하는 요청에 대한 처리를 하는 controller의 method이다. 처음에는 필자의 수정으로 인해 HttpServletRequest 객체가 전혀 사용되지 않았음에도 덩그러니 놓여있다고 생각했는데, 그냥 있는 것이었다. 이를 지워주고 Map 객체를 다루는 내용을 service 안쪽으로 넣어주려고 한다.

 

 Map 객체를 만들고, query 문 성공 여부에 따라 다르게 return 하도록 수정했다. 그리고 해당 성공 여부에 따라 다르게 출력되도록 storeSeat.jsp file을 조금 수정했다.

 

 

 이것으로 SeatService에서 Http 의존성을 제거하면서 모든 logic을 살펴보았다.