[Refactoring] 22.08.14. StoreService Logic에서 Http 의존성 제거

 StoreService에서도 Http 의존성이 굉장히 높은 것을 확인할 수 있다. 이 작업을 시작하기 전까지 다루었던 내용들 상당수가 그렇다. 이미지에서 확인할 수 있는 가장 하단의 카테고리를 추가하는 logic은 작업 시작하기 전에 다루지 않았으며, controller에 있는 나머지 3개의 method에서도 service logic에서의 의존성을 볼 수 있다. 이번 게시글에서는 이 작업을 시작하기 전까지 다루었던 controller의 method까지만을 다룰 것이다. 이어지는 Refactoring 게시글에서는 각 내용에 맞는 수정 작업을 하면서 동시에 Http 의존성을 없앨 예정이다.

 

 

• getList - getList

 Main page loading 에 필요한 매장 정보들과 paging 처리를 위한 data를 가져오기 위해서 Request 객체를 이용해서 request scope에 data를 담고 있다. 이제 StoreService의 getList method에서 Http 의존성을 제거할 것이다.

 

 이전 검색 메인 페이지^[각주:1] 에 대한 refactoring 게시글에서는 해당 logic에 대해 별 다른 수정을 하지 않았었다. 하지만 다시 보니 있었다. 해당 수정과 함께 Http 의존성을 없애볼 것이다.

 HttpServletRequest 객체를 쓰고 있는 이유는 요청과 함께 넘어오는 'pageNum' 에 해당하는 data를 받는 것과 동시에 Request scope를 통해 필요한 data를 front로 넘기기 위해서이다. 이 내용들을 어떤 방식으로 service 바깥으로 전달할 수 있을까?

 가장 먼저 생각난 것은 paging 처리를 위한 data를 다루는 Dto를 하나 더 만들어서 해당 객체를 통해 data를 이동시키는 방법이다. Paging 처리를 필요로 하는 곳은 StoreService와 OrderSerivce 두 곳 으로, 동일하게 startPageNum, endPageNum, totalPageCount, pageNum, List data를 request scope를 통해 front 단으로 data를 전해주고 있었다. 하나 다른 점은 위 이미지에서 볼 수 있는 totalRow에 대한 data인데, 이것이 바로 다시 확인했을 때 사실상 필요없는 data에 해당한다.

 'totalRow' 라는 data는 검색된, 즉 DB에서 select 된 매장의 전체 수를 return 받는 variable이다. 이것이 필요없는 이유는 검색된 data list의 method를 이용해서 size를 바로 알 수 있기 때문에 해당 dao method와 query 문은 존재 자체가 필요없는 것이다. 정말 재미있는 부분은 front 단에서 totalRow와 list.size( ) 를 사용한 부분이 모두 존재한다는 것이다. 과거의 필자에게 돌아가 왜 그랬냐고 묻고 싶다. 따라서 이에 대한 dao method와 query 문을 지우고, DB에서 받아온 list의 size를 통해서 front에서 해당 값을 쓸 수 있도록 수정했다.

 

이어서 Paging 처리를 위한 data를 service 단에서 controller로 넘겨주기 위한 PagingDto를 만들었다. PagingDto는 OrderService에서도 사용해야하기 때문에 generic type으로 만들어주었다.

 

 이 PagingDto 객체를 통해서 service 단에서 request scope로 저장하던 logic을 바꿔주었고, service method는 이 Dto 객체를 return 하도록 수정했다. 그냥 Request 객체를 사용해서 data를 저장해도 되지만, 이왕이면 ModelAndView 객체를 통해 return controller를 return 해도 될 것 같다. 그래서 return 해야할 페이지를 포함해서 ModelAndView 객체로 return 하도록 수정했다.

 

 

• addStore - addStore

 Service의 addStore method에 전달되고 있는 HttpServletRequest 객체로부터의 의존성을 제거할 것이다.

 

 Service method 에서는 Request 객체를 이용해서 email 정보를 불러오고 있었다. 해당 data를 Controller에서 받아 email data를 전달해주는 것으로 수정했고, controller에서는 Request 객체가 아니라 HttpSession 객체를 사용하도록 했다.

 

 

• myStore - getMyStore

 Service의 getMyStore method에 전달되는 HttpServletRequest 객체로부터의 의존성을 제거할 것이다.

 

 Service method 내에서 HttpServletRequest 객체는 session으로부터 email 정보를 가져오는 것과, front 단으로 data를 보내기 위해 사용되고 있었다. 우선 service의 밖에서 email 정보를 받아 method에 email 정보를 전달하도록 수정했다.  문제는 request scope에 data를 담고있는 마지막 부분이다.

 가장 쉽게 해결할 수 있는 방법은, tag의 list에 대한 logic을 controller로 빼내면서 getMyStore method의 return type을 StoreDto로 바꾸는 것이다. 혹은 StoreDto에 해당 List의 값을 받을 수 있는 field를 하나 더 추가하고, List data를 field에 넣어 getMyStore method의 return type을 StoreDto로 바꿔서 controller에서 ModelAndView 객체를 사용해서 controller를 return 해도 될 것이다. 이러면 Dto 안에 그 Dto type을 가진 이상한 꼴이 되어버린다. 그래서 전자의 방법을 택해서 바꿔주었다.

 

 

• addTag - addTag / deleteTag - deleteTag

 Service의 addTag method에 전달되는 HttpServletRequest  객체로부터의 의존성을 제거할 것이다. 그리고 단순히 email data를 받아오기 위한 Request 객체이기때문에 HttpSession 객체를 controller에서 전달받는 것으로 수정했다.

 

 단순히 session scope에서 email data를 받아오기 위해 HttpServletRequest 객체를 사용하고 있어서, service 밖에서 email data를 받아 그 data를 전달하는 방식으로 바꾸었다.

 

 deleteTag method는 add method와 거의 동일하므로 따로 이미지는 첨부하지 않았다. 동일한 방식으로 수정했다. 관련 logic은 다른 게시물에서 수정해서 정리하려고 한다. 아마 바로 다음 게시물이 될 것이다.

 

 

• storeUpdate - updateStore

 Service의 updateStore method는 HttpServletRequest 객체를 사용하고 있지 않게 되어서 사실 이미 Http 의존성이 없는 상태였다. 다음 service logic을 살펴보자.

 

 지난 게시물[footnote][Refactoring] 22.08.10. 매장 정보 관리 (미완) (tistory.com)[/footnotes] 에서 request scope를 통해 data를 전달하고 있었던 부분을 Map 객체를 통해 전달하는 것으로 바꾸면서 HttpServletRequest 객체는 사용되지 않는데, 해당 전달되는 부분을 지워주지 않아서 지워주었다. 더해서 사실 myStore page에서는 전달하고 있는 newDto 의 data를 가지고 화면의 값을 바꿔주는 것이 아니라 입력한 값을 이용해서 그대로 바꿔주고 있어서 newDto라는 이름으로 전달하고 있는 내용을 없애주었다.

 

 

• uploadImage - uploadImage

 Service의 uploadImage method에 전달되는 HttpServletRequest 객체로부터 의존성을 제거할 것이다.

 

 HttpServletRequest 객체는 servlet context 경로를 얻어올 때와 email data를 얻어올 때 사용된다. 따라서 service의 바깥에서 두 data를 받아 method에 전달하는 방식으로 바꾸었다.

 

 

 getMyStore_num method를 제외한 모든 service logic에서 Http 의존성을 제거해주었다.  getMyStore_num method는 매장 상세 정보 페이지 요청에 대한 처리를 하는 controller method에서 사용되고 있으며, 이는 매장 상세 정보 페이지에 대한 refactoring을 진행하는 게시글에서 다루겠다.

1. [Refactoring] 22.08.08. 검색 메인 페이지 (tistory.com) [본문으로]