스프링은 주로 웹 개발에 사용되는데 스프링의 웹 MVC 참조 설명서나 기타 여러 학습 자료를 보면 다음과 같은 유명한 흐름도를 보게 된다.
이 그림은 Spring 설명서에서도 밝히고 있지만 Spring뿐 아니라 그동안 여러 웹 프레임웍에서 사용하던 방식이다. (이 그림이 실제 처리 방식이나 프레임웍들간에 꼭 들어맞지는 않는다. 개념적으로 비슷한 사상을 가지고 있다는 것이다.)
모든 사용자의 요청(즉, 웹 URL)을 "프론트 컨트롤러"라는 서블릿 하나가 받아들인 후 URL에 따라 실제 처리를 담당하는 "컨트롤러"로 요청을 넘긴다. 그러면 컨트롤러는 MVC 구조에 따라 업무 로직을 처리한 후 뷰 정보를 만들어내고 사용자에게 뷰를 보여주는 것이다.
Spring에서는 프론트 컨트롤러는 "디스패처 서블릿"이라고 하고 컨트롤러는 "핸들러"라고 한다.
그런데 그 동안 여러 프로젝트들을 진행하면서 디스패처 서블릿과 관련한 동작 항목들이 위 그림에 있는 것보다 참 다양하구나 하는 것을 알게 됐다. 주로 Spring 설명서에 의존해 Spring을 사용했는데 설명 방식으로 이해하는 것보다는 위 그림처럼 좀더 직관적이면서 기억이 쉬운 흐름도를 직접 만들어보는 게 좋을 것 같았다. 그러기 위해서는 디스패처 서블릿의 소스를 읽으면서 어떤 처리 흐름이 있는지 밟아나가야 했다.
그래서 나온 것이 아래 그림이다. 위 그림에서 디스패처 서블릿의 동작을 좀더 자세히 들여다 본 흐름도라고 볼 수 있겠다.
말로 풀어 설명하자면 다음과 같다. 사용자의 웹 요청이 URL 매핑에 의해 디스패처서블릿으로 들어오면,
- 디스패처서블릿은 핸들러 인터셉터의 preHandle() 메서드를 호출한다. 핸들러 인터셉터는 Spring 사용자가 등록해놓은 사용자정의(custom) 클래스다.
- 디스패처서블릿은 URL에 대응하는(매핑된) 핸들러(컨트롤러)의 메서드를 호출해 업무 로직을 처리하게 한다.
- 디스패처서블릿은 핸들러 인터셉터의 postHandle() 메서드를 호출한다. (1 ~ 3 과정에서 오류(예외)가 발생하면 핸들러 예외 해석기 클래스의 resolveException() 메서드를 호출한다. 핸들러 예외 해석기는 Spring 사용자가 등록해놓은 사용자정의(custom) 클래스다.)
- 디스패처서블릿은 뷰를 처리한다. 일반적으로 jsp include 또는 forward나 redirect가 발생하는 단계다.
- 디스패처서블릿은 핸들러 인터셉터의 afterCompletion() 메서드를 호출한다.
- 디스패처서블릿은 해당 웹 애플리케이션 컨텍스트에 서블릿 요청 처리됐음 이벤트를 발생시킨다.