[Refactoring] 22.08.18. StoreService의 getMyStore Logic에 대하여 (feat. Dao, Mapper)

StoreService의 getMyStore Logic에 대하여

 StoreService에는 매장의 정보를 불러올 수 있는 getMyStore method logic이 존재한다. 그리고 그 logic에서는 getMyStore라는 dao method를 사용하고 있으며, DB에 저장된 매장의 number 정보만을 필요로하는 query 문과는 구분된다. 의문은 다음과 같다.

 

 굳이 query문을 이렇게 둘로 나눌 필요가 있을까?

 

 매장의 정보를 관리하는 페이지로 들어가기 위해 접속한 email 정보와의 일치성을 확인하고, 매장의 정보를 수정하기 위해서 email 정보와의 일치성을 확인하는 것은 다른 유저가 사용하지 못하도록 해야한다는 점에서 올바른 방향성이라고 생각했다. 하지만 그것을 위해 굳이 query 문을 두 가지로 나눌 필요가 있는가에 대한 의문이 들었다. 단순히 요청을 통해 전달받은 number로 정보를 가져온 후, 접속한 email 정보와 다르면 logic을 동작하지 못하게 하고 해당 페이지에서 이탈하도록 하는 방식을 사용해도 되지 않았을까 생각한다.

 이런 방식으로 현재 email 정보와의 일치성을 확인하는 것은 매장 관리 페이지로 진입할 때, 매장의 정보를 변경할 때, 메뉴 정보를 변경할 때이다. 아직 매장에 대한 리뷰, 주문, 자리 관리가 남기도 했다. 그렇다면 또 이런 생각이 든다. 그렇다면 저장된 email data와의 일치성을 확인하는 logic이 여러 군데에 있다면, 이를 각각에 logic으로 넣어줄 것이 아니라, AOP나 Filter를 통해 해결할 수 있지 않을까? Email 정보와의 일치성을 확인 후에 해당 service logic을 수행하도록 한다면 DB 정보를 조회하는 과정을 굳이 둘로 나누지 않아도 될 것이다.

 이렇게 생각하고, 해당 email과 관련된 logic을 모두 없애면서 query문과 그것을 사용하는 dao method를 번호만 가지고 조회할 수 있도록 통일해줄 것이다.

 

 이미지는 MenuService의 메뉴를 추가하는 logic이다. 이 바로 이전에는 메뉴에 대한 category를 추가 및 삭제하는 logic이 있는데, 그곳에서는 이미지 하단처럼 해당 dao method로 불러오는 data가 null 인지 아닌지 여부로 email 정보가 맞는지를 확인하는 logic이 포함되어 있지 않다. 저렇게 불러와지는지의 여부보다 어차피 불러올 것이라면 번호로만 간단히 조회하여 해당 email 정보와 비교하는 편이 조금 더 괜찮아보이기도 하다.

 StoreService의 getMyStore_num method를 지울 생각만 했지, 보다 더 근본적인 고민을 하지 못해서 작업을 한 번 더 하게 된 셈이다. 일단 당장 사용하던 email 정보에 대한 logic을 지웠다. 이는 StoreService에도 구분되어 있는 method를 통일해주기 위함이다. 후에 AOP 등의 작업에서 또 수정하게 될 지 모른다. 별도의 검증 logic을 만든 메뉴 추가/제거 logic에서 검증 logic을 일단 없앴다.

 

 

코드 뜯어보기

StoreMapper.xml

 우선 StoreMapper에서 number data로만 매장 정보를 조회하는 query 문의 이름을 getStoreData 로 바꾸고, email이 아닌 number 만을 조회하도록 바꾸었을 때 발생하는 오류는 Store, Menu, Order, ReviewService이다. 일단 method 이름만 통일해주었다. 기존 email을 포함해서 조회하도록 했어도, number data는 활용하던 상태라 일단은 이름을 통일해주었다.

 

 

MenuService.java

 일단 다른 곳에는 없는 email 까지 넣어 DB의 정보를 가져온 data가 null인지 아닌지 여부를 확인했던 권한 검증 logic을 없애주었다. 해당 logic은 메뉴 추가/제거 관련 logic에만 있는 것이다.