[Refactoring] 22.08.10. Controller와 Business Service Logic (feat. Http)

 리팩터링 중에 Service 객체끼리의 의존성이 존재하는 것에 대한 내용을 찾아보다가, service business logic은 Http 통신을 하는 Request, Session 등의 친구들과는 상관없어야 한다는 내용을 발견했다.^{[각주:1] [각주:2] [각주:3]}

 

/*
 *  [ Controller에서 하는 작업]
 *  
 *  1. 전송된 parameter 추출 가능
 *  2. 특정 요청이 왔을 때 service를 이용해서 business logic을 처리하고
 *     forward 혹은 redirect 이동한다.
 *  3. HttpServletRequest, HttpServletResponse, HttpSession, ModelAndView
 *     등의 객체가 필요하면 method의 인자로 전달 받는다.   
 */
 
 ==============================================================================================

/*
*  service에서 business logic을 처리할 때 필요로 하는 객체를 controller에서 직접 전달해주어야 한다.
*  주로, HeepServletRequest, HttpServletResponse, HttpSession, ModelAndView
*  등등의 객체이다.
*/

 국비 지원 교육에서 들었던 내용 중에 작성한 내용을 그대로 발췌한 것이다. Service에서 business logic을 처리할 때 필요로 하는 객체를 Controller에서 전달해주어야 한다고 적었다. 필자는 이것을 Controller에서 받아서 처리해야한다는 의미로 받아들이고, 전적으로 필자의 잘못으로 지난 시간 계속해서 service business logic에 HttpServletRequest, HttpSession 객체를 넘기고 있었다고 생각하겠다. 그때 강사님께서 Http 의존성에 대한 이야기를 하지 않았을리 없다고 믿는다.

 

 HttpServletRequest 와 HttpSession은 Http 통신을 가정하고 작성한 것이긴 하다. 하지만 Http 통신이 아닌 다른 방식을 사용하게 된다면 모든 service logic까지 수정해야하는 상황에 놓이게 되고, 심하면 새로 만들어야하는 상황에 놓일 수 있다고 한다. 즉, 의존성이 커지게 되어서 재사용의 측면에서 좋지 않게 된다는 의미이다.

 

 그래서 리팩터링 과정이 오래되지 않았기 때문에 다시 처음부터 빠르게 수정하고 넘어가볼 생각이다. 더 나중에 알게된 것이 아니라는 점에 다행이라고 생각하고, 몰라서 벌어진 것이므로 반성하고 다시 작업해보려고 한다. 몰랐다면 그냥 계속 했겠지만, 알게된 이상 그냥 넘어갈 수 없기에 처음으로 돌아간다.

 

 

1. OKKY - 왜 Service단에 Http Request또는 Session을 넣지 않을까요? [본문으로]
2. 온라인 서점 API 만들기로 살펴보는 Spring Boot OOP 3Step03 - 회원가입 Controller 만들기 : 표현영역 효율적으로 관리하기표현 영역1. Request Data값 DTO로 명시적으로 받아서 응용 영역으로 넘기기2. 클라이언트로 부터 넘어오는 데이터 validate 확실하게 하기3. 표현영역에서 사용되는 객체들을 응용 영역에 넘기지않기(ex : HttpServletRequest, HttpServletResponse, HttpSession)4. Domain 객체 바로 프론트엔드로 넘기지 않고 DTO 사용하기마치며 · 大专栏 (dazhuanlan.com) [본문으로]
3. OKKY - service단에서도 model객체 사용 많이 하나요? [본문으로]