해당 포스팅은 참고 사이트에서 읽은 내용을 이해하고자 예제를 따라해본것이니, 참고 사이트 내용을 먼저 읽어보시는 것을 권유드립니다.
[ Dispatcher Servlet 개념 ]
HTTP 프로토콜로 들어오는 모든 요청을 가장 먼저 받아 적합한 컨트롤러에게 위임해주는 프론트 컨트롤러라고 할 수 있다.
클라이언트로부터 요청이 오면 서블릿 컨테이너가 요청을 받게 된다. 그리고 이 모든 요청을 프론트 컨트롤러인 디스패처 서블릿이 가장 먼저 받게 된다. 그러면 디스패처 서블릿은 공통적인 작업을 처리한 후에 해당 요청을 처리할 컨트롤러를 찾아서 위임해준다.
프론트 컨트롤러는 주로 서블릿 컨테이너의 제일 앞에서 서버로 들어오는 클라이언트의 모든 요청을 받아서 처리해주는 컨트롤로로써, MVC 구조에서 함께 사용되는 디자인 패턴이다.
[ Dispatcher Servlet 장점 ]
Spring MVC는 디스패처 서블릿이 등장함에 따라 web.xml의 역할을 많이 축소시켰다.
모든 서블릿을 URL 매핑을 위해 web.xml에 등록해주어야했지만, 디스패처 서블릿이 어플리케이션으로 들어오는 모든 요청을 핸들링해주고, 공통적인 작업을 처리해주면서 상당히 편리하게 이용할 수 있게 되었다. 우리는 컨트롤러만 구현해놓으면 디스패처 서블릿이 알아서 적합한 컨트롤러에게 위임해주기 때문이다.
[ 정적 자원(Static Resources)의 처리 ]
디스패처 서블릿이 모든 요청을 핸들링해주는것은 상당히 효율적으로 보인다. 그렇지만 정적 자원(HTML, JS, CSS 등)의 요청마저 모두 가로채기 때문에, 정적 자원을 못불러오는 일이 발생하였다. 스프링 진영에서는 이러한 문제를 해결하기 위해 2가지 방안을 고려하였다.
- 정적 자원과 애플리케이션의 요청을 분리
- /apps URL로 접근하면 디스패처 서블릿이 담당한다.
- /resource URL로 접근하면 디스패처 서블릿이 담당하지 않는다.
코드가 지저분해지며 모든 요청에 대하여 저런 URL을 적용해야하기 때문에 직관적인 설계가 될 수 없다.
그래서 2번 방법으로 적용되었다.
- 애플리케이션 요청을 탐색하고, 적합한 컨트롤러가 없으면 정적 자원 요청으로 처리
디스패처 서블릿이 먼저 적합한 컨트롤러를 찾고, 요청에 대한 컨트롤러가 없을시 2차적으로 설정 된 자원 경로를 탐색하여 자원을 탐색하는 것이다.
이렇게 영역을 분리하면 효율적인 리소스 관리 방법을 제공해줄뿐더러 확장성에 유리하다.
[ Dispatcher Servlet 동작 과정 ]
- 클라이언트의 요청을 디스패처 서블릿이 가장 먼저 받는다.
- 요청을 위임 할 컨트롤러를 찾는다.
- 요청을 컨트롤러로 위임 할 적합한 Handler Adapter를 찾아서 전달한다.
- Handler Adapter가 컨트롤러로 요청을 위임한다.
- 비지니스 로직을 처리한다.
- 컨트롤러가 반환값을 반환한다.
- Handler Adapter가 반환값을 처리한다.
- 서버의 응답을 클라이언트로 보낸다.
[ 1. 클라이언트의 요청을 디스패처 서블릿이 가장 먼저 받는다. ]
디스패처 서블릿은 클라이언트의 모든 요청을 가장 먼저 받는 프론트 컨트롤러이다.
서블릿 컨텍스트에서 필터들을 지나 스프링 컨텍스트에서 디스패처 서블릿이 가장 먼저 요청을 받게 된다.
실제로는 인터셉터가 컨트롤러에게 요청을 위임해주지는 않지만, 순서도를 표현하자면 아래 그림과 같다.
[ 2. 요청을 위임 할 컨트롤러를 찾는다. ]
디스패처 서블릿은 요청 정보를 바탕으로 적합한 컨트롤러를 찾고 해당 메소드를 호출한다.
주로 @RestController @Controller @RequestMapping 관련 어노테이션을 조합하여 컨트롤러를 생성하므로, 요청을 처리할 컨트롤러는 HandlerMapping의 구현체중 하나인 RequestMappingHandlerMapping가 찾아준다.
해당 객체는 내부에서 HashMap으로 요청 정보, 처리 대상을 캐싱하고 있어서, 요청 정보를 Key로 사용하여 요청을 처리할 대상을 찾아온다. 이때 요청을 처리할 대상은 컨트롤러가 아닌 컨트롤러를 가진 HandlerMethod 객체이다. HandlerMethod를 갖는 이유는 컨트롤러와 컨트롤러 메소드 등을 포함해 부가적인 정보들이 필요하기 때문이다.
그리고 찾아온 HandlerMethod를 HandlerMethodExecutionChain으로 감싸서 반환되는데, 그 이유는 컨트롤러로 요청을 넘겨주기 전에 처리해야 하는 인터셉터 등을 포함하기 위함이다.
[ 3. 요청을 컨트롤러로 위임 할 적합한 Handler Adapter를 찾아서 전달한다. ]
디스패처 서블릿은 컨트롤러로 직접 요청을 위임하는게 아니라 Handler Adapter를 통해 어댑터 패턴으로 컨트롤로에 요청을 위임한다.
어댑터 인터페이스를 사용하는 이유는 컨트롤러의 구현 방식이 다양하기 때문이다.
스프링은 오래전에 만들어진 프레임워크로 트렌드를 굉장히 잘 따라간다. 프로그래밍 흐름에 맞게 스프링 역시 변화를 따라가게 되었는데, 그러면서 다양한 코드 작성 방식을 지원한다.
그래서 다양하게 구현 된 컨트롤러에 대응하기 위해, 스프링은 Handler Adapter 라는 어댑터 인터페이스를 통해 어댑터 패턴을 적용함으로써 컨트롤러의 구현 방식에 상관없이 요청을 위임할 수 있도록 설계되어있다.
[ 4. Handler Adapter가 컨트롤러로 요청을 위임한다. ]
핸들러 어댑터가 컨트롤러에게 요청을 넘기기전에, 공통적인 전처리 과정이 필요하다. 요청에 매핑되는 인터셉터를 실행시키고, @RequestParam, @RequestBody 등으로 파라미터를 변형시키는 ArgumentResolver도 실행하는 등의 다양한 공통 작업을 수행한다.
이러한 전처리 과정이 끝나면 파라미터 값들과 함께 컨트롤러에 요청을 위임한다.
[ 5. 비지니스 로직을 처리한다. ]
컨트롤러는 서비스를 호출하여 비지니스 로직을 처리한다.
[ 6. 컨트롤러가 반환값을 반환한다. ]
비지니스 로직이 처리된 이후에는 컨트롤러가 반환값을 반환한다. 응답 데이터를 반환하는 경우에는 주로 ResponseEntity를 반환하고, 응답 페이지를 반환하는 경우에는 String으로 view의 이름을 반환한다.
[ 7. Handler Adapter가 반환값을 처리한다. ]
핸들러 어댑터는 컨트롤러가 반환 한 반환값을 응답 처리기인 ReturnValueHandler가 후처리한후에 디스패처 서블릿으로 반환값을 넘겨주게 된다.
만약 컨트롤러가 ResponseEntity를 반환한다면, HttpEntityMethodProcessor가 MessageConverter를 사용해 응답 객체를 직렬화하고 응답 상태를 설정한다.
컨트롤러가 view name을 반환한다면, view를 반환하기 위한 준비 작업을 처리한다.
[ 8. 서버의 응답을 클라이언트로 보낸다. ]
디스패처 서블릿을 통해 반환되는 응답은 필터를 거쳐 클라이언트에게 전달된다. 이때 응답이 데이터라면 그대로 반환되지만, View라면 ViewResolver가 해당되는 화면을 찾아서 반환한다.
