EP4. 스프링 MVC 구조

Spring MVC 전체 구조

스프링 MVC - 김영한 (인프런)

처음 HTTP 요청이 들어오면 URL에 매핑된 핸들러(컨트롤러)를 조회한다.

Dispatcher Servlet은 처음 Http 요청이 들어오는 곳을 한곳으로 통일하고 여기서 핸들러(컨트롤러)를 분배하기 위해서 존재한다.

 

그리고 해당 핸들러가 지원하는 방식이 무엇인지 핸들러 어댑터 목록에서 조회한다.

 

최근 실무에서는 99.9퍼센트 애노테이션 기반의 핸들러(컨트롤러)를 사용하지만,

스프링은 기존 프레임워크 구조를 깨지않고 계속 발전해왔기 때문에 기존에 지원하던 핸들러들도 지원해야했다.

 

그래서 핸들러 어댑터 목록을 조회하는 것이 필요하다.

 

Dispatcher Servlet 입장에서는 조회한 핸들러 어댑터만 호출하면 핸들러 어댑터에서 알아서 핸들러를 찾아 호출하고 핸들러 어댑터는 model, view를 반환한다. 여기서 view는 "논리 이름"이다. 절대경로가 아니다.

 

그래서 viewResolver가 존재한다.

논리이름 ex) "member-form" 을 viewResolver에게 전달하면 

(InternalResourceViewResolver에)

prefix = "/WEB-INF/views/"

suffix = ".jsp"

라고 되어있는 viewResolver에서 "/WEB-INF/views/member-form.jsp" 를 반환한다.

 

 

viewResolver는 논리이름 -> 절대이름(절대경로)로 만들어주는 것이다.

 

 

 

정리하면

HTTP요청 -> 핸들러조회 -> 핸들러어댑터조회 -> 핸들러어댑터를 통해 핸들러 호출 -> Dispatcher Servlet에 Model, View 반환 -> viewResolver 호출 -> 완성된 ViewName에 Model 전달 -> HTML 응답