스프링 MVC 라이프사이클
일단 현재까지 정리한 개념에 대해서는 Filter 부분을 제외한 나머지는 다 공부를 하였다.
Filter에 대한 부분은 Spring Security와 함께 따로 정리할 것이다 (앞으로)
하지만 일단 전체적인 흐름에 관해 다시 잡고 갈 것이다.
Filter -> DispatcherServlet -> HandlerMapping -> HandlerAdapter -> Controller -> Service -> Repository -> ViewResolver -> View -> Filter 순으로 전체적인 라이프 사이클이 흘러간다고 생각하면 된다.
Filter
(2024.01.25) 현재는 정리를 한 내용이 없긴 하다. 하지만 천천히 블로그에 정리해놓겠다.
-
말 그래도
Filter, 필터 역할을 한다고 보면 된다. -
DispatcherServlet으로 들어가기 전에 거를 것은 거르고 본다고 생각하면 된다.
-
Spring Security 부분과 같이 생각을 해보면 된다.
- 해당 웹 브라우저에 들어가기 위해서는 로그인이 필요한 곳이거나, 인가가 된 사람 이외에는 들어갈 수 없을 경우, 이러한 경우에 Filter 역할을 통해 통과가 되지 못하게 만든다.
DispatcherServlet
-
웹 브라우저에서 요청한 Request에 대해 Controller 단으로 들어가기 전에 먼저 처리해주는 곳이다.
-
우선, HandlerMapping에게 요청한 Request에 대해 매핑할 정보가 Controller에 있는지 검색 요청을 보낸다.
-
HandlerMapping으로부터 해당 Controller 정보를 반환받아서 그에 맞는 Controller와 매핑시킨다.
-
즉, 요청받은 Request에 대한 정보를 어느 Controller에 매핑시킬 것인지 작업을 해주는 곳이라고 보면 된다.
HandlerMapping
- DispatcherServlet으로부터 요청 받은 검색에 대한 내용의 Controller를 찾아서 해당 정보를 반환해주는 곳이다.
HandlerAdapter
- DispatcherServlet에서 보낸 HttpServletRequest, HttpServletResponse 객체를 전달 받고, 내부 로직에서 Controller를 실행하는 역할을 한다.
Controller
-
요청 받은 Request에 대해 어떤 로직으로 처리할 것인지 결정하는 곳이다 (Service)
-
특정 로직으로 처리하기 위해서 Service의 Bean을 스프링 컨테이너로부터 주입받아와야 한다.
Service
-
데이터를 처리하고 가공을 하기 위한 비즈니스 로직을 수행하는 곳이다.
-
요청 받은 Request에 대해 실질적으로 데이터 로직을 수행하고 Repository를 통해 DB에 접근하여 CRUD를 처리한다.
Repository
-
실제 DB와 연결하는 객체이다.
-
Service에서 DB에 접근할 수 있께 하며 데이터의 CRUD를 도와준다.
ViewResolver
-
Controller에서 리턴한 View의 이름을 DispatcherServlet으로부터 넘겨받고, 해당 View를 렌더링하고 DispatcherServlet으로 리턴한다.
-
DispatcherServlet에서는 해당 View 화면을 응답해준다.
-
만약 View가 필요 없고 데이터 (JSON 형식)으로만 받고 싶다면 ViewResolver는 필요가 없다.
(@Controller -> @RestController or 해당 메서드 위에 @ResponseBody를 사용하면 된다.)
