인프런 스프링부트 개념정리(이론)
이 글은 다음 강의의 이론 정리 글 입니다.
디스패처 서블릿이 무엇인가요?
FrontController 패턴
최초 앞단에서 request 요청을 받아서 필요한 클래스에 넘겨준다.
왜? web.xml에 Servlet/JSP 매핑 시(web.xml에 직접 매핑 or @WebServlet 어노테이션 사용)에 모든 클래스에 매핑을 적용시키기에는 코드가 너무 복잡해지기 때문이다.
이때 새로운 요청이 생기기 때문에 request와 response가 새롭게 new될 수 있다. 그래서 아래의 RequestDispatcher가 필요하다.
최초의 요청이 왔을 때, URI 요청 혹은 자바파일 요청이 오면 자원으로 바로 접근하지 못하고 톰캣으로 간다. request가 처음 웹서버에 들어올 때 BufferedReader를 사용해서 받은 가변 길이의 문자를 가지고 톰캣으로 가면 자동으로 객체(request, response)로 만들어준다. request 객체는 요청한 사람의 정보(어떤 데이터를 나에게 요청했는지, 어떤 데이터를 들고 들어왔는지 등)를 담고 있다. response 객체는 request 객체를 토대로 응답해줄 객체이다. 이렇게 객체로 만들어주면 자바에서 request.변수, request.함수처럼 쓸 수 있게 되는 장점이 있다.
이제 최초 앞단에서 request 요청을 받았을 때 .do라고 하는 특정 주소를 요청받는다면 FrontController로 보내라는 약속의 코드를 web.xml에 짜놨다고 가정해보자.
a.do가 request로 웹서버에 들어와서 FrontController가 넘겨 받으면 여기서 FrontController는 한번 더 자원에 접근하는 request를 보낸다. 원래 외부에서 내부로 오는 요청이 URI 혹은 자바 파일일 경우 자원으로 바로 접근을 못하지만, 내부에서 내부로 가는 요청은 가능하다. 이 때 톰캣에 있는 reqeust, response 객체가 새로운 request에 맞춰서 덮어씌워진다.
이 때, 기존의 request, response를 지우지 않는 방법이 있을까?
RequestDispatcher를 사용하면 된다. 기존 request가 a 데이터를 가지고 있으면 새로운 b 요청이 들어와도 기존의 request를 재사용하기 때문에 a 데이터를 유지할 수 있다.
RequestDispatcher
필요한 클래스 요청이 도달했을 때 FrontController에 도착한 request와 response를 그대로 유지시켜준다.
DispatchServlet
FrontController 패턴을 직접 짜거나 RequestDispatcher를 직접 구현할 필요가 없다. 왜냐하면 스프링에는 DispatchServelet이 있기 때문이다. DispatchServlet은 FrontController 패턴 + RequestDispatcher이다.
DispatchServlet이 자동 생성되어 질 때 수 많은 객체가 생성(IoC)된다. 보통 필터들(+Spring 어노테이션들)이다. 해당 필터들은 내가 직접 등록할 수도 있고 기본적으로 필요한 필터들은 자동 등록되어진다.
