[Spring 기초 이론] 디스패처 서블릿

FrontController 패턴

문지기가 web.xml에 너무 많은 Servlet/JSP 정의가 들어있으면 매핑하는 내용이 굉장히 많아지기 때문에 web.xml에 다 정의하기가 힘들다. 따라서 최초 앞단에서 request 요청을 받아서 FrontController에 넘겨준다. 

 

 

여기서 a.do, b.do가 자원에 내부적으로 request를 다시 보내면 기존에 톰캣이 자동으로 생성해준 request, response를 다시 정의해야 한다. 그러면 기존의 정보들이 사라지니까 새로운 기법을 사용해야 한다. 

 

재요청시에 최초의 request, reponse를 다시 새로 정의하는 것이 아니라 기존의 정보를 유지하고 덮어씌우는 requestDispatcher라는 기법을 사용한다. 

 

RequestDispatcher

필요한 클래스 요청이 도달했을 때 FrontController에 도착한 request와 response를 그대로 유지시켜준다.

 

A라는 사람이 a.jsp 파일을 요청했으면 a.html 파일을 응답받을 것이다. A라는 사람은 웹 브라우저로 요청했기 때문에 화면에 a.html이 띄워질 것이다. a.jsp에 대한 request와 response 객체가 만들어졌을 것인데 만약 그 화면에서 또 새로운 b.jsp 파일을 요청하면 b.html을 응답받을 것이다.

 

새로운 요청이 일어났으므로 request, response가 사라졌을텐데 이 때 이걸 막기 위해 RequestDispatcher 방식을 사용하는 것이다. 

 

DispatchServlet

스프링에서는 FrontController와 RequestDispatcher의 기능을 가진 DispatchServlet을 제공해준다. 이것을 사용하면 FrontController 패턴을 직접 짜거나 RequestDispatcher를 직접 구현할 필요가 없다. 

 

DispatchServlet이 자동생성되어 질 때 수많은 객체가 생성(IoC)된다. 보통 필터들이다. 

 

 

 

 

 

 

 

출처

[무료] 스프링부트 개념정리(이론) - 인프런 | 강의