FrontController 패턴
최초 앞단에서 request 요청을 받아서 필요한 클래스에 넘겨준다. 왜? web.xml에 다 정의하기가 너무 힘듬.
문지기가 web.xml에 너무 많은 jsp에 대한 정의가 많으면 매핑 하는 내용이 굉장히 많아진다. 그래서 앞단에서 request 요청을 받으면 frontcontroller에 넘기는것이다.
예를들어 request에 .do 라는 특정주소가 들어오면 frontcontroller로 보내라는 약속의 코드를 web.xml에 짜놓는다.
최초의 요청이 uri, 혹은 자바파일이면 자원에 접근을 못하고 톰켓으로 간다. 그러면 request가 response라는 객체를 만든다. request는 요청한 사람의 데이터를 가지고 있다. 어떤 데이터를 요청 했는지, 어떤 데이터를 들고 들어왔는지 등, 이것을 토대로 response 객체를 만든다. 이 request와 response를 톰켓이 자동으로 만들어준다.
원래는 통신은 buffered로 들어오는데, 가변길이 문자를 받는다. 이걸 받아서 톰켓이 객체로 만들어준다.
-> 자바-변수, request.함수 사용가능하게 만들어주는것이다.
만약 a.do, b.do요청을 받으면 frontcontroller로 가고, frontcontroller가 이 요청들이 자원으로 갈 수 있게 다시 한번 request를 한다. 스프링은 자원 접근을 막아놓는다고 앞서 말했지만, 내부에서는 접근이 가능하다.
이 request가 일어나면 실제로는 톰켓이 받은 request가 새로운 request, 새로운 response로 바뀐다. 즉, 새로 frontcontroller의 request를 새로 만드는것이 아니라 기존에 있던 request에 덮어 씌우는것이다. 그래서 기존의 request와 response를 다시살리는 방법이 필요하다.
그런데 기존에 있는 request와 response를 없애지 않고 그대로 들고가서 다시 요청하는 방법이 있다. request와 response는 생성될때마다 새로 만들어지는데, frontcontroller에서 새로 요청을 할때 기존의 request response를 유지하는 기법이 requestDispatcher를 이용하는 것이다. 그러면 사라지지 않고 재사용이 가능하다.
어떤 A가 a.jsp를 요청하면 a.html을 응답해준다.
그럼 a.jsp 요청에 대한 request와 response가 만들어진다.
이때 a.html에 있는 버튼을 눌렀을때 b사이트로 갈때 b.jsp 요청을 보내고 b.html을 응답받는다. 그럼 b.html이 열린다.
처음 request와 response를 a.html가 들고있는데, 그냥 하면 b.html로 넘어갈때 이것들이 사라진다.
사라지지 않게 하기 위해 requestDispatcher방식으로 이해하면 a.html에 있는 request와 response를 b.html에 가져오고 a.html에 있는 데이터를 그대로 사용할 수 있다. 그리고 requestDispatcher방식을 이용해야 데이터를 들고 페이지사이를 이동할 수 있다.
FrontController 패턴을 직접짜거나 RequestDispatcher를 직접구현할 필요가 없다. 왜냐하면 스프링에는 DispatcherServlet이 있기 때문이다. DispatcherServlet은 FrontController 패턴 + RequestDispatcher이다.
DispatcherServlet이 자동생성되어 질 때 수 많은 객체가 생성(IoC)된다. 보통 필터들이다. 해당 필터들은 내가 직접 등록할 수 도 있고 기본적으로 필요한 필터들은 자동 등록 되어진다.
