DispatcherServlet는 비유적으로 설명하자면 학교 행정실(중앙 처리 방식)과 같다고 할 수 있다.
학생 → 학교 행정실(중심)에 문의를 하면,
학교 행정실(중심) → 교수님에게 문의를 하고,
교수님 → 학교 행정실(중심) 에게 답변을 통보하고
다시 학교 행정실(중심) → 학생들에게 결과를 통보한다.
즉, 가장 중심에 DispatcherServlet이 있고 DispatcherServlet이
(View, ViewResolver, Controller, HandlerMapping)와 각각 상호 작용하는 방식으로 동작한다..!
ViewResolver와 View 는직접적으로 상호 작용하는 것이 아니다.
반드시 DispatcherServlet를 거쳐 가야만 한다.
어렵게 생각하지말고 DispatcherServlet 역시 서블릿이니 자바 파일이다.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc</artifactId>
<version>5.3.37</version>
</dependency>
우리가 따로 코드를 짤 필요가 없이
pom.xml에 spring-web 의존성 설정을 통해서 미리 만들어준 것을 가져와서 잘 쓰기만 하면 된다..ㅎ
이때, 디스패처 서블릿을 프론트 컨트롤러 역할을 하는데,
서버의 앞단에서 클라이언트의 요청에 알맞는 컨트롤러를 찾아가도록 분배해주는 역할을 한다.
기존 서블릿 프로젝트에서는 Controller 클래스로 만든 것도 역시 프론트 컨트롤러이다.
다만, 기존 프로젝트에서는 프론트 컨트롤러에서
Command.properties 를 통해 Map 방식으로
/api/user/update = UserUpdateService 매핑을 해주었다.
(기존 프로젝트에서) 프론트 컨트롤러에서 Service 인스턴스를 직접 호출했지만,
이제는 Controller A, B, C .. 를 한 번 더 거쳐 간다.
( 기존 프로젝트) 프론트 컨트롤러(ControllerServlet) -> Service 에서
(스프링MVC) 프론트 컨트롤러(디스패처서블릿) -> Controller -> Service->Repository로 흐름이 진행한다.
예를 들어, UserController, BoardController, ReviewController 등등 한 번 더 거쳐 Service로 간다.
***필터(참고 사항)****
필터는 클라이언트의 요청이 디스패처 서블릿에 도달하기 전에 필요한 설정을 하거나 특정 요청을 차단하는 역할을 해준다.
ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ톰캣이 시작할 때 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
0. 톰캣이 실행되면서 web.xml을 읽는다.!
1. <servlet> 태그 안에 설정된 DispatcherServlet 이 메모리에 뜬다.(실행 대기 상태가 된다.)
url-pattern에 따라 *.do로 끝나는 요청이 들어오면 <servlet-name>에 맞는 servlet-name이 dispatcherServlet로 정의된 서블릿이 실행될 것이다.
<servlet>
<servlet-name>dispatcherServlet</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
2. <init-param> 태그 안에 xml 파일이 추가적으로 로딩된다.
위의 xml 파일에 설정된 bean 객체가 메모리에 올라간다.(싱글톤 방식으로)
HandleMapping -> 얘는 디스패처가 실행되면서 알아서 실행됨
Controller -> 위의 xml 읽을 때 싱글톤 빈 생성
ViewResolver -> 위의 xml 읽을 때 싱글톤 빈 생성
ㅡㅡㅡㅡㅡㅡㅡㅡ클라이언트 요청이 들어오면 ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ
0. 필터를 통해서 필요한 설정과 요청 차단이 이뤄진다.
이때는 DispatcherServlet에 요청이 도달하기 전이다.
1. 프론트 컨트롤러인 DispatcherServlet이 요청을 인식하고 URL을 HandlerMapping에게 전달한다.
2. HandleMapping은 해당 URL과 일치하는
@RequestMapping(value="input.do", method=RequestMethod.GET)를 찾는다.
즉, HandlerMapping은 URL에 알맞는 Controller(A, B, C ..) 컨트롤러를 찾는다.
3. 매핑된 결과<컨트롤러 + 해당 메소드 정보>를 DispatcherServlet에 전달한다.
4. DispatcherServlet은 해당 Controller와 @RequestMapping에 맞는 메소드를 실행시킨다.
5. 즉, Controller + RequestMapping에 맞는 메소드 아래의 코드 실행된다.
@RequestMapping(value="input.do", method=RequestMethod.GET)
public ModelAndView input(){
ModelAndView mav= new ModelAndView();
System.out.println("dd2");
mav.setViewName("input"); //jsp 파일명을 넣어달라 //web-inf/view/hello.jsp
return mav;
}
6. Controller에서 ModelAndView에 뷰의 이름 + 데이터 정보를 담아서 다시 DispatcherServlet에 전달한다.
7. DispatcherServlet은 ModelAndView 안에 View의 이름을 ViewResolver에게 전달한다.
(매번 /WEB-INF/spring/★ ★ ★.jsp를 쓰는 것은 너무나도 귀찮기 때문에 편의성을 위해서
prefix(앞)와 suffix(뒤)를 자동으로 붙여 주는 역할을 한다.)
8. ViewResolver는 prefix랑 suffix를 붙인 풀네임 경로를 다시 DispatcherServlet에 전달한다.
9. DispatcherServlet는 위에서 구한 실제 경로를 바탕으로 실제 View 파일을 찾는다.
(실제 jsp , html 파일 위치...)
10. jsp는 서버 사이드 랜더링 방식이므로 ModelAndView 에서 데이터까지 뽑아내서 jsp 코드에 삽입이 이뤄진다.
11. 이제 HTTP Response 응답을 해줘야 하므로 10번에서 데이터까지 꽂아넣은 결과를 ResponseBody에 담아서 보낸다.
12. 클라이언트의 웹브라우저에서 11번의 jsp 코드를 Response Body에서 읽어 브라우저에 띄운다.
이해하기 아주아주 좋은 그림