DispatcherServlet

 

ServletContainer SpringContainer

위에 저번글에서 다룬 내용중 서블릿에 대해 정리를 해보았습니다..

근데 저는 개발을 하면서 스프링부트를 주로 이용하였지만 스프링프레임워크도 한 번 경험이 있엇는데..

위에 글의 내용과 같이 web.xml에서 각 서블릿에 맞는 매핑을 설정을 해줘야한다고 했는데..

그런적은 한 번도 없고 dispatcherServlet를 사용하였다

 

그럼 dispatcherServlet는 뭘까..?

스프링MVC에서는 dispatcherServlet를 구현하여 controller에 매핑을 시켜준다.

javaEE로만 이용을 하여 서블릿을 만들며 할 경우에는 web.xml에 등록 각 서블릿클래스를 만들고 구현을 해줘야한다..

근데 이게 점점 더 확장이 되면서 규모가 커지면.. 작성하는 양이 어마어마할 것이고 관리하기가 어려워질 것이다.

 

dispatcherServlet는 frontController로써 서버로 요청이 들어올때 제일 먼저 앞에서 요청을 받아주며 각 controller에 맞게 뿌려준다.

그림을 보며 이해를 해보자

 

출처 : https://lazymankook.tistory.com/69

 

이미지가 제일 잘 나온것을 찾아봤다...

 

1. 요청이 들어온다.

2. handlerMapping에서 요청에 맞는 handler가 있는지 조회를 한다.

3. handler를 처리할 수 있는handlerAdapter를 조회한다.

4. 조회 후 존재 시 handlerAdapter에게 위임을 해준다 그리고 handler에 매개변수로 넣어줄 객체를 생성하기위한 처리를 위해 argumentResolver(HandlerMethodArgumentResolver)에게 위임 바디에 데이터가 있을 경우 MessageConverter에게 처리를 위임을 해준다.

5.이 과정중에 처리 후 ReturnValueHandler 혹은 바디에 데이터를 실어야하는 경우 MessageConverter 에게 처리를 하고 

return값이 viewName이면

6.viewResolver에게 보내

7,8.  view를 retuen한다.

 

실제로는 훨씬 더 복잡한 로직으로 이루어져있지만... 기본적인 flow을 알아야 더 이해가 간다고 생각해서 정리...

 

+ 추가...

 

이렇게 보면 dispatcherServlet로 서블릿이다.

일반 그냥 서블릿으로 구현을 했을 경우에는 java코드에 html등의 코드도 다 들어가 있어서 가독성과 너무 조잡해서 알아보기 힘든 경우가 많다고 한다. 그리고 서블릿에 대해 등록을 해줘야 하니까 번거롭기도 하고... @webServlet으로 인하여 좀 나아지긴 했지만 ...

 

그래서 jsp가 나와서 html같은 공간에 자바코드를 넣어서 개발을 한다. serverSide 스크립트 언어이다. 어찌보면 서블릿과 반대 같지만 똑같은 역할을 한다. 서블릿의 역할에 +_추가 기능이라고 할까...

 

서블릿(controller)와 Jsp(view)의 장점을 살려서 mvc를 구현을 한다...

 

어찌댓건 사진을 보면서 구조를 이해하는게 제일 좋은 거 같다.

위에 사진이 인터넷에 제일 좋게 나와있다고 본다 시큐리티를 모르면 시큐리티 부분은 안봐도 되고... 사진을 어디서 저장을 했는데 출처가 기억이 안난다...(아시면 알려주세요).

 

 

암튼 이제는 dispatcher 서블릿을 이용을 할 것이다.

근데 dispatcher 서블릿는 하나만 있는게 아니고 1개 이상 여러개가 있을 수 있다...(필요로 한다면..?)

흔히 ServletAppliationContext에는 controller,handlerMapping,intercepter등등... 이 있고,

RootAppliationContext에는 DAO,DB등이 있다고 한다.

 

RootAppliationContext의 자식 ServletApplicationContext는 여러개가 존재 할 수 있지만, 굳이 사용을 안한다고 한다.

그래서 그 자식들이 공통적으로 부모(RootAppliationContext)빈들을 접근할 수 있는 것이다.

이런식으로 안되면 각각 dispatcher 서블릿마다 RootAppliationContext 가 생성이 되어서 중복되는 빈들이 존재할 것이다..

 

 

 

dispatcher 서블릿 안에 존재한다고 보면 안되고 앞단에 있다고 보면 될 것같다. 저 위에 사진은 1:1로 이루어져있고 더 많은 ServletWebApplicaionContext를 만들 수 있다... 그런데 위에 말하다시피 굳이 프론트컨트롤러역할로 모든 요청을 분기할 수 있는 dispatcher 서블릿이 있는데 굳이 이렇게 계층구조로  만든 이유가 무엇일까...

전체 애플리케이션에 서 웹기술에 의존적인 부분과 아닌 부분을 구분하기 위해서라고 한다...

비즈니스계층과 데이터계층은 스프링으로 이용하여 만들었지만.. 프레젠테이션계층은 다른걸로도 만들 수 있으니까...

이상...

 

 

references

Tomcat, Spring MVC의 동작 과정 (taes-k.github.io)

Tomcat, Spring MVC의 동작 과정

토비의 스프링 3.1