이번에는 Spring MVC에서 중요한 역할을 하는 Dispatcher Servlet에 대해 정리해보겠습니다.
Dispatcher Servlet 이란?
디스패쳐 서블릿은 HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에 전달해주는 프론트 컨트롤러(Front Controller)입니다.
Dispatcher Servlet 특징
- 프론트 컨트롤러 패턴 : 모든 요청을 가장 먼저 받아 공통적인 작업을 처리한 후에 적절한 컨트롤러에게 위임합니다.
- 정적 자원과 동적 자원을 분할 처리 : 디스패처 서블릿에 요청이 들어오면 해당하는 컨트롤러를 찾는다. 해당하는 컨트롤러가 없는 경우 정적 자원을 탐색한다. 이를 통해 효율적인 리소스 관리가 가능해집니다.
Dispatcher Servlet 장점
디스패쳐 서블릿은 web.xml의 역할을 축소시켰습니다. 과거에는 모든 서블릿 web.xml에 등록해야 했지만 디스패쳐 서블릿이 모든 요청을 핸들링하고 공통 작업을 처리하면서 편리하게 이용할 수 있게 되었습니다. web.xml에 등록하지 않고 컨트롤러를 구현하기만 하면 디스패쳐 서블릿이 알아서 적절한 컨트롤러로 위임을 해줍니다.
디스패처 서블릿이 도입되기 전에는 각 컨트롤러마다 공통 로직을 복붙 형식으로 작성하여 사용했습니다. 디스패처 서블릿이 도입된 이후 공통 로직 처리가 가능해져 효율적으로 요청 처리가 가능해졌습니다.
- 효율적인 요청 관리 : 모든 요청을 중앙에서 처리함으로 효율적으로 할 수 있습니다. web.xml에 등록하는 수고를 줄이고 공통 로직 처리를가능하게 합니다.
- 보안 강화 : 중앙에서 요청을 관리함으로 보안 관련 처리를 일관되게 적용할 수 있습니다.
- 코드의 재사용성, 유지보수 : 각각의 컨트롤러의 작업을 공통 작업으로 처리할 수 있어 재사용성과 유지보수 높아집니다.
Servlet 이란?
서블릿이란 자바를 사용하여 웹 페이지를 동적으로 생성하는 프로그램입니다.
서블릿은 클라이언트의 요청을 처리하고 결과를 반환하는 웹 프로그래밍 기술입니다.
디스패처 서블릿도 서블릿의 한 종류로 서블릿을 상속 받으면서 특화된 역할을 수행합니다.
프론트 컨트롤러(Front Controller)란?
프론트 컨트롤러는 웹 애플리케이션 디자인 패턴 중 하나로 모든 요청을 단일 진입점을 통해 처리하는 구조를 말합니다. 이 패턴은 주로 MVC 아키텍처에서 사용합니다.
프론트 컨트롤러 패턴의 장점
- 일관된 요청 처리 : 요청에 대한 일관된 방식으로 처리(인증, 로깅 등)
- 보안 강화 : 단일 지점을 통과하기에 보안 관련 처리를 중앙에서 관리
- 재사용성 및 유지보수 증가 : 공통적인 요청 처리 로직 수행 가능
web.xml 이란?
web.xml은 Java EE 웹 애플리케이션에서 서블릿, 필터, 리스너 등 웹 관련 설정이 포함되어 있습니다. URL 패턴으로 서블릿에 매핑하는 설정, 요청 전후에 수행되는 필터 매핑 설정 등을 저장했습니다.
디스패처 서블릿은 web.xml 파일의 복잡한 설정 작업을 줄여 개발자가 더 직관적이고 간결한 방식으로 애플리케이션을 구성할 수 있게 했습니다.
서블릿 매핑 자동화하여 모든 HTTP 요청을 적절한 컨트롤러로 전달했습니다. 이는 web.xml에 서블릿 매핑을 정의하는 수고를 줄였습니다.
Dispatcher Servlet의 동작 과정
Dispatcher Servlet은 맨 처음 요청을 받고 적합한 컨트롤러와 메소드를 찾아 요청을 위임합니다. 그 과정은 다음과 같습니다.
- 클라이언트 요청을 Dispatcher Servlet이 받는다.
- Dispatcher Servlet은 Handler Mapping을 통해 요청에 알맞는 컨트롤러를 찾는다.
- Dispatcher Servlet은 Handler Adapter에게 요청을 위임한다.
- Handler Adapter가 컨트롤러에 요청을 위임한다.
- 컨트롤러는 비즈니스 로직을 처리하고 결과값을 반환한다.
- View Resolver는 반횐된 뷰 이름으로 뷰 객체를 찾습니다.
- View 객체가 모델 데이터를 사용하여 최종적으로 클라이언트에게 보여줄 화면을 생성한다.
- 생성된 화면을 클라이언트에게 응답으로 반환한다.
위의 과정을 하나씩 알아보겠습니다.
1.클라이언트 요청을 Dispatcher Servlet이 받는다.
HTTP 요청이 들어오면 디스패처 서블릿이 요청을 처음으로 받습니다. 이 때, 필터를 통해 요청을 받기 전 작업을 처리합니다.
2. Dispatcher Servlet은 Handler Mapping을 통해 요청에 알맞는 컨트롤러를 찾는다.
핸들러 매핑은 URL과 해당 URL을 처리할 컨트롤러의 매핑 정보를 가지고 있습니다. 디스패처 서블릿은 핸들러 매핑을 통해 해당 URL을 처리할 적절한 컨트롤러를 찾을 수 있습니다.
3. Dispatcher Servlet은 Handler Adapter에게 요청을 위임한다.
디스패처 서블릿은 해당 컨트롤러로 요청을 직접 위임하는게 아니라 핸들러 어댑터를 통해 위임합니다. 그 이유는 컨트롤러의 구현 방식이 다양하기 때문입니다. 과거에는 컨트롤러를 Controller 인터페이스로 구현했는데 현재에는 @Controller 어노테이션 구현합니다. 다양하게 작성되는 컨트롤러에 대응하기 위해 스프링은 핸들러 어댑터를 통해 어댑터 패턴을 적용해서 컨트롤러의 구현 방식에 상관 없이 요청을 위임할 수 있게 했습니다.
4. Handler Adapter가 컨트롤러에 요청을 위임한다.
핸들러 어댑터가 컨트롤러에게 요청을 위임합니다. 위임 전,후에 작업을 처리합니다. 대표적으로 인터셉터들이 동작을 합니다.
5. 컨트롤러는 비즈니스 로직을 처리하고 결과값을 반환한다.
컨트롤러는 서비스를 호출하고 개발자가 작성한 비즈니스 로직을 진행하고 결과값을 반환합니다. 결과값이 view 이름이라면 view resolver를 통해 뷰 객체와 매핑하고 모델 데이터로 랜더링 한 다음 반환합니다. 결과값이 데이터를 반환하면 직렬화를 통해 JSON, XML 등으로 만들고 뷰 리졸버, 랜더링 작업을 생략하고 HTTP 응답 본몬으로 클라이언트에게 전송됩니다.
6. View Resolver는 반횐된 뷰 이름으로 뷰 객체를 찾습니다.
컨트롤러에 반환된 뷰 이름을 기반으로 뷰 리졸버가 실제 뷰 객체를 찾고 경로를 알려줍니다.
7. View 객체가 모델 데이터를 사용하여 최종적으로 클라이언트에게 보여줄 화면을 생성한다.
뷰 객체가 모델 데이터를 사용하여 클라이언트에게 보여줄 화면을 랜더링 합니다.
8.생성된 화면을 클라이언트에게 응답으로 반환한다.
생성된 화면(HTML, JSON 등)을 클라이언트에게 응답으로 전송합니다.
마무리
이번에는 Dispatcher Servlet에 대해 정리했습니다.
정리하자면 Dispatcher Servlet은 HTTP 요청을 맨 처음 받아 적절한 컨트롤로에게 위임하는 프론트 컨트롤러 였습니다. Dispatcher Servlet을 사용하면 web.xml에 일일이 서블릿을 등록해야하는 수고로움을 덜 수 있고 공통적인 작업을 처리하여 보안과 재사용성이 높아지는 장점이 있었습니다.
감사합니다.
