[Refactoring] 22.08.12. UsersService Logic에서 Http 의존성 제거

 UsersService의 method를 보면 상당히 많은 HttpServletRequest와 HttpSession 객체를 전달하고 있는 것을 볼 수 있다. 이제부터 이들에 대한 의존성을 제거하는 작업을 할 것이다.

 

 

• ajaxLogin - loginProcess

 Ajax로 로그인 과정을 거치는 controller의 method이다. HttpSession이나 HttpRequest와 같은 객체를 service 단에 넘기는 것은 Http 통신에 의존성을 높여 재사용을 어렵게 한다는 글을 보고 수정하는 첫 부분이다. 로그인을 위해 session 영역에 로그인 한 email 정보를 남기기 위해서 HttpSession을 사용한 것이다.

 

 그래서 service logic을 보면 마지막 즈음 session에 'email' 이라는 이름으로 로그인한 email data를 저장하고 있다. 이 부분을 바깥으로 빼려면, service logic에 있는 isValid에 어떤 값이 들어가는지도 바깥인 controller에서도 알 수 있어야 한다. 생각난 방법은 두 가지이다. 첫째는 service에서 return 하는 map 객체의 "isValid" key의 value를 조회하는 방법이고, 둘째는 service의 return type을 Dto로 하면서 Dto에 isValid와 isExist 에 대한 값을 넣을 수 있도록 field를 추가해주는 방법이다. 하지만 결국은 JSON 으로 응답해야하는 부분이므로 이미지의 logic을 그대로 사용하기로 했다. Service logic에서는 단순히 HttpSession 객체를 사용하는 부분을 빼준 것이고, 해당 logic은 다음 이미지와 같이 controller에 옮겨주었다.

 

 

 

• info - getInfo/getMyStores/getList

 마이 페이지로의 이동에 대한 controller의 method이다. 상당한 의존성을 보이고 있는데, 차근차근 수정해보고자 한다.

 

 우선 가장 먼저 UsersService의 getInfo service logic이다. 접속한 email data를 얻기위해 HttpSession 객체를 전달받았으나, 해당 객체를 service 단으로 들여오지 않고 controller에서 미리 변수로 받은 값을 전달받아 logic을 수행할 수 있도록 바꾸었다. 더해서 ModelAndView 객체 또한 service 단까지 들어올 필요가 없기 때문에 service 바깥으로 옮겨주었다.

 

 다음은 StoreService의 getMyStores service logic이다. 마찬가지로 email 정보를 얻기위해 HttpServletRequest 객체를 사용하지만, controller에서 변수로 받은 email data를 전달받도록 바꾸면서 Request 객체에 저장하던 값은 controller에서 ModelAndView 객체에 저장할 수 있도록 했다.

 

 마지막은 OrderService의 getList service logic이다. 마찬가지로 email 정보는 controller에서 미리 변수로 받은 값을 전달하면서 logic을 지웠고, paging 처리를 위한 pageNum data 또한 email 처럼 controller에서 미리 변수로 받은 값을 전달하면서 logic을 지웠다.

 

 Service logic의 가장 마지막에는 paging 처리를 위한 여러 값들을 ModelAndView 객체에 담아 return 하고 있었다. ModelAndView 객체가 아닌 Map 객체를 이용하려고 한다.

 

 

 특히 이 세 service logic의 변화로 StoreController와 ReviewController에서도 수정을 해주어야 했다.

우선 StoreController이다. 나중에 다시 올테지만, Request 객체를 받지 않고 email 정보를 그대로 전달해주었다.

 

 다음 ReviewController의 내용은 test logic이었기 때문에 그냥 지워주었다.

 

 

• getUser - getData

 지난 번에는 수정하고 싶은 내용이 없었지만 지금은 HttpSession으로 인한 의존성을 제거해주려고 한다.

 

 역시나 email data를 활용하기 위해 HttpSession 객체를 활용하고 있었고, 이 단계를 service 바깥으로 옮겨주었다.

 

 한 가지 의문점은, 바로 직전 info method에서 사용하고 있는 UsersService의 getInfo method와 어떤 차이가 있는 것인가 하는 것이다. 이전에 변동사항이 없어서 짚고 넘어가지 않은 부분이지만, 이 controller의 method는 navigation bar에서  페이지가 로딩되자마자 바로 ajax로 요청해서 받아오는데에 사용되고 있었다.

 

 

• update - updateUser

 마찬가지로 email data를 활용하기 위해 HttpSession 객체를 사용하고 있었고, 이 단계를 service 바깥으로 옮겨주었다.

 

 

 

• ajaxProfileUpload - saveProfileImage

 Request 객체의 getServletContext method를 사용해서 webapp 까지의 실제 경로를 얻어내고 있었다.

 

 그래서 Request 객체를 사용하는 부분을 service 바깥으로 옮기고, 실제 경로값을 가진 data를 service logic 안쪽으로 넘기는 방식으로 바꾸어주었다.

 

 

• pwdUpdate - updateUserPwd

 HttpSession 객체를 사용하고 있는 것을 보니 email data를 다루고 있을 것이다.

 

 HttpSession 객체는 두 군데에서 쓰이고 있었다. 첫 번째는 session scope에서 email data를 불러올 때 사용하고 있었고, 두 번째는 비밀번호를 변경한 이후 session scope에서 email 이라는 이름으로 된 data를 삭제하는 것으로 로그아웃 처리를 하고 있었다. 두 logic을 모두 service 바깥에서 수행할 수 있도록 바꾸었다.

 

 

• getOrderUser - getOrderDate

 Request 객체를 사용하고 있어서 무엇인가 싶었는데, email data를 받아오고 있었다. 해당 controller의 method는 매장 관리 페이지의 주문 관리 항목에서 ajax로 경로 요청을 하고 있는데, 페이지가 로딩될 때 해당 email data를 이용해서 해당 email 정보로 주문된 내용을 받아오고 있었다.

 

 일단은 의문점에 앞서서 Request 객체를 이용해서 전달받은 email data를 받아오는 과정을 service 바깥으로 옮겨주었다.

 

 의문점은 페이지를 출력하는 것과 동시에 화면에 정보를 띄우는 것이 아니라, 구조만 만들어두고 script 영역이 실행될 때 ajax 요청으로 data를 받아 끼워넣는 방식을 취한 이유가 무엇인지에 대한 것이다. 굳이 이렇게 data를 두 번에 걸쳐 받아와야 하는 이유가 무엇이었을까?

 Front 단은 웬만하면 손대지 않으려고 하기 때문에, 이곳에 문제가 있다는 정도만 기록하고 넘어가는 것으로 하겠다.

 

 

• delete - deleteStore/deleteUser

 여기서도 또한 Request 객체를 받아오는 이유가 무엇인지 궁금했는데, 그저 email data를 얻기 위함이었다. 그래서 HttpSession 객체를 이용하도록 하나로 통일하였고, service 내에서 해당 내용을 controller 쪽으로 가져왔다.

 

 

 우선 UsersService의 deleteUser method 먼저 보겠다. Email data를 위해 HttpSession 객체를 사용하고 있으므로, 해당 logic을 service 밖으로 빼주면서 해당 method에는 email 정보를 전달하는 것으로 바꾸었다.

 

 다음은 StoreService의 deleteStore method이다. 사실 이 service method가 이번 Http 의존성 제거 작업을 시작하기 전 작업하던 부분이다. 이 method는 매장 하나의 정보를 삭제할 때도 쓰이고, 회원 탈퇴를 하면서 관리하던 전체의 매장 정보를 삭제할 때도 쓰인다. 두 경우의 차이는 넘어오는 Dto 객체에 number data가 있는지 여부였다. 해당 내용은 이어서 StoreController의 service logic에서 Http 의존성을 없애준 뒤 생각해보려고 한다.

 두 경우에 모두 email data를 필요로 하는 것은 동일하기때문에, 마찬가지로 email data를 바깥에서 받아오는 방식으로 수정했다.

 

 이 내용을 수정하면서 StoreController에서 사용하는 deleteStore method에도 영향을 미쳐 오류가 발생했는데, Request 대신 HttpSession 객체를 쓰도록 바꾸면서 수정해주었다.

 

 

 이렇게 모든 Service logic에서 Http 의존성을 제거해주었다. 작업을 진행하면서 드는 생각은 요청과 응답은 Request와 Response인데, 왜 Response 객체는 사용하지 않았는가에 대한 의문이다. 실제로 수업에서 언급은 했지만 실습 등으로 사용했던 기억은 없고, 그래서 프로젝트에서도 사용하지 않았다. 이 UsersController 에서는 사용해볼만한 곳이 당장 보이지는 않지만 이에 대해 고민할 필요도 생긴 것 같다.