스프링 MVC request 구조 이해 용 글
웹 요청 → 스프링 MVC → 화면 응답
이 과정은 거의 식당에서 주문 받고 음식 나오는 과정과 똑같다.
1) Client (손님)
- 웹브라우저
- 메뉴 주문하듯 요청을 보내는 사람
➡ 서버(식당)에 “/menu/list” 를 주문함
→ HTTP Request
2) DispatcherServlet (식당의 총 접수 창구·매니저)
- 스프링 MVC의 핵심
- 모든 요청이 가장 먼저 도착하는 곳
- 직접 음식을 만들지는 않음
- “이 주문을 어느 주방에 보내야하지?” 하고 배분하는 역할
➡ Client의 요청을 받고, 누구에게 전달할지 판단해야 함
3) HandlerMapping (메뉴판 + 주문-요리 매칭표)
- 어떤 URL 요청이 어떤 Controller 메소드로 가야 하는지 알려줌.
- “/menu/list 요청은 MenuController의 list()로" 같은 매핑표 제공
➡ DispatcherServlet이 이것을 보고 어디로 가야할지 알아냄
4) HandlerAdapter (조리 보조 시스템)
-
DispatcherServlet이 Controller를 직접 호출할 수 없어서
중간에서 호출 규칙을 맞춰주는 변환기
-
쉐프가 중국인이라 통역기가 필요한 상황.
➡ DispatcherServlet → HandlerAdapter → Controller 순서로 호출됨
5) Handler(Controller) (주방장)
- 실제 비즈니스 로직을 처리하는 핵심
- 고객 요청에 따라 데이터를 준비하고 모델을 만듦
➡ 결과로 Model + View 이름 반환
(또는 ModelAndView)
6) ViewResolver (완성된 요리를 어느 그릇(HTML)으로 담을지 결정하는 주체)
- Controller가 “result” 같은 논리 이름을 반환하면 이것을 실제 파일로 바꾸는 역할
예:
- “result” →
/templates/result.html - prefix + viewName + suffix 로 실제 파일찾기
➡ 최종 보여줄 View 객체를 반환함
7) View (손님에게 나가는 실제 음식 = HTML 화면)
- ViewResolver가 찾아준 실제 템플릿 파일
- Model 데이터를 넣어서 최종 HTML으로 렌더링
- 손님(Client)에게 응답으로 나감
전체 흐름 7단계로 끝내기 (초간단 버전)
- Client: “/menu/list” 요청 보냄
- DispatcherServlet: 요청 받음
- HandlerMapping: 해당 요청은 MenuController.list()로 가라고 안내
- HandlerAdapter: 컨트롤러 호출 방식 맞춰줌
- Controller: 로직 실행 → Model + View 이름 반환
- ViewResolver: View 이름을 실제 HTML 파일로 매핑
- View: 데이터를 넣어 HTML 생성 → Client에게 응답
정리
Client가 요청 → DispatcherServlet이 받고 → HandlerMapping에서 목적지 찾고 → HandlerAdapter로 방식 맞춰 → Controller가 처리 → ViewResolver가 템플릿 찾고 → View가 HTML 만들어서 답장.
백엔드