[Refactoring] 22.08.16. UsersController와 StoreController에서 여러 service logic 호출하는 method 살펴보기

Controller에서 하나의 service logic 만을 호출하도록?

 지난 게시글에서 StoreService의 deleteStore에 대한 logic을 고민하면서 분기했던 logic을 UsersService의 deleteUser에 옮겨서 하나의 service logic으로 만들어서 UsersController의 delete method에서 하나의 service logic만을 호출하도록 바꾸었다. 이번 게시글에서는 그 나머지 마이 페이지 이동에 대한 호출인 UsersController의 info, StoreController의 검색 메인 페이지 호출에 대한 main과 매장 상세 정보 페이지 호출에 대한 goStoreDetail 에서는 어떤지를 살펴보려고 한다.

 

코드 뜯어보기

UsersController.java

• info

 UsersController의 info method에서는 접속중인 회원의 정보, 회원이 관리하는 매장 list, 회원이 주문한 내역에 대한 정보와 paging 처리에 필요한 정보를 request scope를 통해 front로 넘기고 있다. 그리고 해당 정보들을 각각의 service logic을 통해 넘기고 있다.

 우선 하나로 묶는지의 여부를 판단하기 전에 이들이 transaction이 필요한 service logic인지를 살펴야한다. 세 service logic 모두 DB의 data를 바꾸는 logic이 아니라 단순히 data를 가져가기만 하는 logic이기때문에, 이들을 굳이 하나의 service logic으로 만들 필요는 없다고 생각한다. (이미 하나의 service logic으로 바꿔서 commit 하고 push 한 이후에 이 사실을 깨달은 것은 비밀이 아니다.)

 

 대신 바꿔주고 싶은 몇 가지 내용들을 잘못된 작업을 통해 찾을 수 있었다.

 

 첫 번째는 StoreService의 getMyStores method를 사용해서 넘기는 data는 접속한 회원이 가진 매장의 List 정보인데, front에서는 그 List data가 아닌 List의 size 값만을 사용하고 있었다. 그러면 List 전체의 data보다 List의 size 값만을 넘겨준다면 보다 더 효율적이라고 생각해서 해당 부분을 바꿔주면서, front에서 다른 이름으로 받을 수 있도록 수정해주었다.

 

 두 번째는 마지막 OrderService의 getList에서 굳이 필요없는 dao method를 사용하고 있던 점이다. 이미 email data로 주문 내역을 List로 받은 상태에서, 다시 query 문을 통해 조회하여 주문 내역의 수를 받아올 필요는 없다. 때문에 List의 method를 사용하는 것으로 수정하면서 동시에 해당 dao method를 지워주고 Mapper.xml에서 query 문 또한 지워주었다. 해당 내용들은 다른 곳에서 전혀 사용되지 않는다.

 

 

StoreController.java

• main

 메인 페이지로의 경로 요청에 대한 getList method도 바로 전 UsersController의 info 처럼 단순히 DB의 data를 얻어오는 logic이다. 따라서 service logic을 하나로 만들지 않아도 될 것 같다.

 

• goStoreDetail

 메인 페이지에서 매장 상세 정보 페이지 요청에 대한  goStoreDetail method도 마찬가지로 단순히 DB의 data를 얻어오는 logic 뿐이다. 따라서 service logic을 하나로 만들지 않기로 하며, 다른 내용과 다르게 아직 Http 의존성이 남아있는 이유는, 매장 상세 정보 페이지 관련 내용을 따로 게시글로 다루기 위함이다.