2. DispatcherServlet 이란?

Dev StoryTeller·2021년 2월 14일

Spring 시리즈!

목록 보기

31/33

드디어 시작되는 DispatcherServlet!
해당 클래스는 Servlet의 중심이자, Spring MVC의 중심이다.
이것을 이해하는 것이 곧 Spring MVC를 이해하는 것과 같다고 할 수 있을 정도로 중요한 요소이다 : )
그럼 한번 자세히 알아보자

0. DispatcherServlet의 의미

Dispatcher Servlet에서 Dispatch의 의미는 급파하다, 파견 등의 의미로,
해석해보면 받은 요청을 어딘가로 빨리빨리 보내는 서블릿이라는 뜻이다.
또한 프론트 컨트롤러라고 불리기도 한다.

과연 어디로 보낸다는 걸까? 프론트 컨트롤러라면 컨트롤러의 종류 중 하나인걸까?
지금부터 이에 대해 자세하게 알아보자.

0. 배경?

동작 원리나 특징 등을 살펴보기 전에, 왜 DispatcherServlet이 그렇게 대단한 건지 먼저 살펴보려 한다.
그러기 위해 일단 Spring이 없는 환경으로 돌아가보자
.
.
.

1. 지저분해지는 프로젝트

Spring이 없는 JAVA 런타임에서는 컨트롤러가 존재하지 않는다.
따라서 우리는 서블릿 객체를 생성하고, 그것을 web.xml에다 일일히 다 등록해줘야 했다.

<!-- 서블릿1 등록 -->
<servlet>
    <servlet-name>서블릿1</servlet-name>
    ...
</servlet>
<servlet-mapping>
    <servlet-name>서블릿1</servlet-name>
    ...
</servlet-mapping>

<!-- 서블릿2 등록 -->
<servlet>
    <servlet-name>서블릿2</servlet-name>
    ...
</servlet>
<servlet-mapping>
    <servlet-name>서블릿2</servlet-name>
    ...
</servlet-mapping>

<!-- 서블릿3 등록 -->
<servlet>
    <servlet-name>서블릿3</servlet-name>
    ...
</servlet>
<servlet-mapping>
    <servlet-name>서블릿3</servlet-name>
    ...
</servlet-mapping>

하지만 웹사이트를 이용해봤다면 알겠지만, 우리가 접속하는 페이지(경로)는 한두개가 아니다.
메뉴 페이지, 로그인 페이지, 관리자 페이지 등 아무리 적게 잡아도 최소 10개이다.

게다가 컨트롤러와는 달리 서블릿 객체 하나는 하나의 경로만 담당한다.
이렇게되면 10개보다 더 늘어날 것이고,
프로젝트 문서는 온통 서블릿 객체로 넘쳐날 것이다.

2. 높은 의존성

Servlet 객체는 HttpServlet를 확장한 객체이다.
이렇게 되면 HttpServlet 기능을 필수로 Override 해야 하고, 더이상 일반 객체로 사용할 수 없다.
즉, 클래스끼리 값을 주고받기가 까다로워진다는 것!

3. 중복되는 작업

모든 서블릿이 공통으로 처리하는 작업이나, 가장 우선시 되야하는 작업이 분명 있을 것이다.
이런 것을 서블릿 객체로 처리하기란 불가능하고, 매우 까다로울 것이다.

이외에도 여러가지가 있겠으나, 필자가 경험한 단점은 위와 같다.

1. 특징

DispatcherServlet은 이러한 단점들을 모두 해소해주고, 간편하게 사용할 수 있다.

1. Controller의 등장

서블릿을 더이상 HttpServlet을 확장하지 않고, POJO를 사용한다.
@Controller 어노테이션을 붙여서 간편히 사용할 수 있으며, 의존성이 낮아져서 다른 객체들과 연계가 자유롭다.

Servlet 객체

/* Servlet 객체 */
@WebServlet("/user")
public class testServlet extends HttpServlet {
    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // GET 작업 처리
    }

    @Override
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // POST 작업 처리
    }
    
    @Override
    protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        // 서블릿 동작 처리
    }
}

Controller 객체

@Controller
public class testController {
   @PostMapping("/user")
   public String userPage() {
      // POST 처리
   }
   
   @GetMapping("/user")
   public String userPage() {
      // GET 처리
   }
}

2. 2차 컨트롤러 구조

Controller가 생겨났음에도 불구하고, 여전히 web.xml에 일일히 등록해야 했다.
하지만 컨트롤러가 다음과 같은 구조를 띄면서 문제는 사라졌다.

위와 같은 구조를 필자는 2차 컨트롤러 구조라고 부른다.
원래라면 web.xml에 각 컨트롤러를 모두 등록해야 하지만,
DispatcherServlet이 모든 요청을 받고 세부 경로는 각 Controller에게 뿌려주는 프론트 컨트롤러의 역할을 함으로써, web.xml에 서블릿을 일일히 등록할 필요가 없어졌다.