💡DispatcherServlet이란?
DispatcherServlet은javax.servlet.http.HttpServlet을 상속한 클래스로서, Spring MVC의 핵심 프론트 컨트롤러 역할을 수행하는 클래스이다.
클라이언트의 모든 요청을 중앙에서 받아 적절한 컨트롤러로 전달하고, 처리 결과를 View로 연결해주는 역할을 한다.
@SpringBootApplication에 의해 자동으로 등록되며, 기본 URL패턴인/에 매핑 된다.
✅DispatcherServlet의 도입 배경
DispatcherServlet은 기존 서블릿 기반 웹 애플리케이션 개발의 비효율성과 복잡성을 해결하기 위해 도입되었다.
1. 요청 처리 방식의 중복과 비효율성
과거 서블릿 기반의 개발방식에서는 요청을 처리하기 위해 매번 HttpServlet을 상속받아 doGet()이나 doPost() 메서드를 오버라이드해야 했다. 각 URL마다 서블릿을 하나씩 매핑해야 했기 때문에 구조가 점점 복잡해지고, 공통된 처리 로직이 여러 서블릿에 반복되는 문제가 발생했다.
2. 공통 기능 중복 문제
로그인 여부 확인, 요청 인코딩 설정, 공통적인 예외 처리 등은 거의 모든 서블릿에서 필요하지만, 이를 매번 각각의 서블릿에 작성했어야 했다. 이렇게 되면 유지보수가 어려워지고, 애플리케이션 전체의 일관성을 유지하기도 쉽지 않았다.
3. MVC 패턴 적용의 어려움
MVC 패턴을 적용하고 싶어도 서블릿 기반 개발에서는 모델, 뷰, 컨트롤러를 명확하게 분리하기가 쉽지 않았다. 모든 흐름을 개발자가 직접 조합해야 하고 요청 처리 후 어떤 뷰로 포워딩할지 결정하거나 데이터를 뷰에 전달하는 작업도 수동으로 처리해야 했기 때문에 구조화된 설계를 유지하기가 어려웠다.
4. 프론트 컨트롤러 패턴의 필요성
이런 문제들을 해결하기 위해 등장한 것이 바로 프론트 컨트롤러 패턴이다.
프론트 컨트롤러는 모든 요청을 하나의 진입점에서 받아 공통 처리를 한 뒤, 적절한 컨트롤러로 요청을 전달하는 구조이다.
프론트 컨트롤러를 통해 요청 흐름을 통합하면 공통 작업 처리, 일관성 있는 구조, 유지보수 용이성을 확보할 수 있다.
5. DispatcherServlet의 등장
Spring Web MVC에서 이 역할을 맡는것이 바로 DispatcherServlet이다.
DispatcherServlet은 웹 애플리케이션의 모든 요청을 한 곳에서 받아들이고, 그 요청에 알맞은 컨트롤러를 찾아 전달하며, 처리 결과를 다시 뷰로 연결해주는 중심 역할을 해준다.
덕분에 요청 흐름을 일관되게 관리할 수 있고, 공통 기능을 재사용하며, 명확한 구조로 개발할 수 있게 되었습니다.
✅DispatcherServlet의 주요 역할
1. 요청 수신
- 클라이언트의 요청을 가장 먼저 받는다(
/,*.do등 매핑 가능)
2. 핸들러 매핑
HandlerMapping을 통해 어떤 컨트롤러(핸들러)가 이 요청을 처리할지 결정
3. 핸들러 어댑터 실행
- 핸들러(@Controller 메서드)를 호출 가능한 형태로 변환하고 실행
4. 모델과 뷰 반환
- 컨트롤러의 실행 결과로
ModelAndView객체 생성
5. 뷰 리졸버 처리
ViewResolver를 통해 논리적 이름(view name)을 실제 뷰 파일로 변환
6. 최종 렌더링
- 실제 뷰를 렌더링하고 클라이언트에게 응답 전송
✅DispatcherServlet 처리 흐름
1. 클라이언트의 요청을 DispatcherServlet이 받음
2. HandlerMapping을 통해 해당 요청을 처리할 컨트롤러를 찾음
3. 해당 컨트롤러가 실행할 수 있는 HandlerAdapter를 찾아서 전달
4. HandlerAdapter가 컨트롤러로 요청을 위임
5. 컨트롤러가 비즈니스 로직을 처리
6. 컨트롤러가 반환값을 반환
7. HandlerAdapter가 반환값을 처리
8. 서버의 응답을 클라이언트로 반환
➡️1. 클라이언트의 요청을 DispatcherServlet이 받음
- 디스패처서블릿은 가장 먼저 요청을 받는
프론트 컨트롤러로써, 클라이언트의 모든 요청을 가로챈다.
➡️2. HandlerMapping을 통해 해당 요청을 처리할 컨트롤러를 찾음
- DispacherServlet은 요청을 처리할 핸들러(컨트롤러)를 찾고 해당 객체의 메소드를 호출한다. 이 때, 어느 컨트롤러가 요청을 처리할 수 있는지 식별해야하는데, 그 역할을 하는것이
핸들러 매핑이다. - 핸들러 매핑 구현체가 URL, HTTP 메서드 등을 기준으로 어떤 컨트롤러 메서드가 이 요청을 처리할지 결정하게 된다.
➡️3. 해당 컨트롤러가 실행할 수 있는 HandlerAdapter를 찾아서 전달
- 다양한 핸들러(@Controller, @RestController, HttpRequsetHandler 등)을 일관된 방식으로 실행하기 위해 적절한 핸들러 어댑터를 찾는다.
➡️4. HandlerAdapter가 컨트롤러로 요청을 위임
- 핸들러 어댑터가 컨트롤러로 요청을 위임한다.
➡️5. 컨트롤러가 비즈니스 로직을 처리
- 컨트롤러는 Service를 호출하고, 우리가 작성한 비즈니스 로직들을 처리한다.
➡️6. 컨트롤러가 반환값을 반환
- 비즈니스 로직이 처리된 후에는 컨트롤러가 반환값을 반환한다.
- 응답데이터를 사용하는 경우에는 ResponseEntity를, 응답페이지를 보여주는 경우라면 view의 이름을 반환할 수도 있다.
➡️7. HandlerAdapter가 반환값을 처리
- 만약 컨트롤러가 ResponseEntity를 반환하면
MessageConverter를 사용해 객체를 직렬화하고 응답상태(HttpStatus)를 설정한다. - 컨트롤러가 View 이름을 반환하면
ViewResolver를 통해 실제 뷰 파일 경로를 찾아 View 객체로 변환한다.
➡️8. 서버의 응답을 클라이언트로 반환
HttpServletResponse를 통해 HTML, JSON, 파일 등 최종 응답 결과가 전송된다.
