Spring : DispatcherServlet

 

Dispatcher-Servlet

 

Dispatcher-servlet 에서 Dispatch는 보내다 라는 뜻을 가지고 있습니다.

Servlet Container에서 HTTP프로토콜을 통해 들어오는 모든 요청을 프레젠테이션 계층의 제일앞에 둬서 중앙집중식으로 처리해주는 프론트 컨트롤러(Front Controller)

 

클라이언트로부터 어떠한 요청이 들어오면 Tomcat 과 같은 서블릿컨테이너가 요청을 받습니다.

 

그 때 제일 앞에서 서버로 들어오는 모든 요청을 처리하는 프론트 컨트롤러 를 스프링에서 정의하였고,

 

이를 Dispatcher-Servlet 이라고 합니다.

 

공통처리 작업을 Dispatcher 서블릿이 처리한 후 적절한 세부 컨트롤러로 작업을 위임해줍니다.

 

Dispatcher-servlet 이 처리하는 url 패턴을 지정해주어야 하는데 일반적으로는 /*.do 와 같이 / 로 시작하고

 

.do 로 끝나는 url 패턴에 대해서 처리하라고 지정해줍니다.

 

 

 

---

 

Dispatcher-servlet 의 장점

 

Spring MVC 는 Dispatcher-servlet 이 등장함에 따라 web.xml 의 역할을 많이 축소시켜 주었습니다.

 

기존에는 모든 서블릿에 대해 url 매핑을 활용하기 위해 web.xml에 등록해주어야 했지만,

 

Dispatcher-servlet 이 해당 어플리케이션으로 들어오는 모든 요청을 핸들링 해주면서 상당히 편리해졌습니다.

 

Dispatcher-servlet 의 기능 처리를 그림으로 보면 아래와 같습니다.

 

Dispatcher-servlet 흐름

 

Dispatcher-servlet 이 요청을 Controller로 넘겨주는 방식은 효율적으로 보이지만,

 

모든 요청을 처리하다 보니 img 파일이나 HTML 파일을 불러오는 요청까지 모두 Controller로 넘깁니다.

 

JSP 파일안의 JavaScript 나 CSS 파일들에 대한 요청도 모두 Dispatcher-servlet 이 가로채는 바람에

 

파일을 불러오지 못하는 상황도 종종 발생할 수 있습니다.

 

이에 대한 해결책은 첫번째로 클라이언트의 요청을 2가지로 분리하여 구분하는 것입니다.

 

1. apps 의 url 로 접근하면 Dispatcher-Servlet 이 담당.
2. resources 의 url 로 접근하면 Dispatcher-Servlet 이 컨트롤할 수 없으므로 담당하지 않음

이러한 방식을 사용하게 되면 코드가 지저분해지고 모든 요청에 대해 url을 붙여주기 때문에 직관적인 설계가 불가능 합니다.

 

두번째 방법으로는 모든 요청을 컨트롤러에 등록하는 것입니다.

 

하지만 두번째 방법을 사용하게 되는건 무식하게 코딩하는것과 같습니다.

 

 

 

Spring은 이런 문제들을 해결하기 위해 편리한 방법을 제공해 주었습니다.

 

바로 <mvc:resources /> 를 이용한 방법입니다.

 

만약 Dispatcher-servlet 에서 해당 요청에 대한 컨트롤러를 찾을 수 없는 경우에

 

2차적으로 설정된 경로에서 요청을 탐색하여 자원을 찾는 것입니다.

 

이렇게 하면 효율적인 리소스관리를 지원하고 추후에 확장을 용이하게 해주는 장점이 있습니다.