Dispatcher Servlet은 뭔데요?

Dispatcher Servlet에 대해 알아보기 전에 아래 글에서 서블릿에 대해 알아보고 오자!

⬇️

서블릿이 뭐에요?

 

그럼 이제 이런 서블릿들이 있는데, 뭔가 이상하다고 느낄 부분이 있을 것이다.

 

현재는 아래와 같이 요청들이 처리 된다.

인프런 김영한 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

이렇게 되면 각각의 서블릿에서 컨트롤러로 클라이언트의 요청을 처리한다. 근데 이러면 중복되는 부분이 너무 많아질 수 있다.

 

그래서 클라이언트 요청을 받는 서블릿 하나만 앞단에 두고 해당 서블릿이 요청 경로에 따라 컨트롤러를 매핑하게 바꿀 수 있다.

인프런 김영한 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

이것을 프론트 컨트롤러 패턴이라하고, 스프링에서는 DispatcherServlet이 프론트 컨트롤러 역할을 수행한다.

 

그럼 여기에서 드는 의문. 이제 그러면 DispatcherServlet만 Servlet Container에서 관리되고 Controller 들은 스프링 컨테이너에서 관리되나요? 맞습니다. 서블릿은 이제 최초 진입 통로 역할만 하고 실질적인 로직 처리는 스프링 빈으로 관리되는 Controller에서 담당하게 된다. 참고

FrontController 도입에 따른 Servl... - Inflearn | Community Q&A

 

그러면 프론트 컨트롤러를 도입하면 어떤 프로세스로 처리되는지 더 자세히 알아보자.

 

영한님의 강의에서는 v1 ~ v5에 따라 개선된 프론트 컨트롤러 도입 방식을 설명해주신다. 그 중 v3부터 보자

인프런 김영한 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

프론트 컨트롤러에서 매핑 정보에 따라 컨트롤러를 호출하면 컨트롤러는 ModelView를 반환한다. 이 때 ModelView는 다음과 같다.

public class ModelView {
    private String viewName;
    
    private Map<String, Object> model = new HashMap<>();
    
    public ModelView(String viewName) {
    	this.viewName = viewName;
    }
    
    // getter, setter
}

ModelView를 보면 서블릿 기술을 전혀 사용하지 않는 것을 볼 수 있다. 이렇게 되면 구현도 쉽고 테스트도 쉬워진다.

실제로는 ModelAndView로 구현되어 있다.

 

어쨌든 다시 돌아와서 이 때 ModelView의 viewName에는 view의 전체 경로가 아닌 논리적인 이름이 담겨져 있다. 예를 들어 "

/WEB-INF/views/test.jsp"와 같이 물리적인 이름이 아니라 "test"와 같이 논리적인 이름이 담겨져 있다.

 

이러한 논리적인 이름을 물리적인 이름으로 바꿔주는 부분을 viewResolver가 담당한다.

 

그 후에 MyView에서 랜더링 작업을 처리한다.

 

솔직히 여기까지만 봐도 굉장히 잘 설계된 프론트 컨트롤러이다. 그런데 개발자의 입장에서 항상 ModelView 객체를 생성하고 반환하는 부분이 번거로울 수 있다. 그래서 컨트롤러에서 ModelView 대신 ViewName만 반환하도록 개선한 v4 버전이 있다.

인프런 김영한 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

컨트롤러의 코드를 한번 비교해보자

v3

v4

막 그렇게 큰 차이는 아닌데 결과적으로 보면 더 깔끔하게 코드를 작성할 수 있게 되었다. 둘을 비교해보면 model도 프론트 컨트롤러에서 생성해서 전달해주었기 때문에 훨씬 깔끔하게 컨트롤러 코드를 작성할 수 있게 되었다.

 

이제 v5는 v3과 v4 방식을 모두 사용할 수 있게 만든 방식이다. 즉, 어떤 개발자는 v3으로, 어떤 개발자는 v4로 개발하고 싶을텐데 이를 모두 수용할 수 있게 일종의 컨트롤러 인터페이스를 구현하여 적용한 방식이다.

인프런 김영한 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

요청 url로 해당 url에 맞는 핸들러를 찾아온다. 그러면 핸들러 어댑터 중에서 해당 핸들러를 처리할 수 있는 핸들러 어탭터를 찾아온다. 그리고 그 핸들러 어댑터로 핸들러를 처리한다.

url에 매핑되어 있는 핸들러(컨트롤러)들

맞다. 우리가 앞에서 컨트롤러라고 했던 애가 사실 핸들러였고 이런 핸들러들은 초기에 생성되어 있다.

 

그리고 핸들러 어댑터는 ModelView를 반환한다. 그런데 v3에서나 ModelView를 반환했었지 v4에서는 반환 안했었는데? 그러면 새로 만들어서라도 반환해줘야 한다.

 

그 후에 처리 방식은 다 똑같다. viewResolver로 물리적인 이름으로 바꿔주고 랜더링된다.

 

그래서 여기에서 Dispatcher Servlet은 뭔데요??

인프런 김영한 스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

당연히 이때까지 얘기했던 프론트 컨트롤러가 우리가 그렇게 궁금해하던 Dispatcher Servlet이다!

 

실제 스프링 MVC는 이러한 방식으로 구현되어 있고, 이렇게 인터페이스 방식으로 유연하게 구현된 덕분에 새로운 방식을 자유롭게 추가 가능하다. 가장 최근에 나온 어노테이션 방식(@Controller)도 이렇게 기존 방식이 유연하게 설계되어 있기 때문에 쉽게 확장될 수 있었다.

 

역시 스프링 GOAT