Wanna be Brilliant Full-Stack Developer

2/28 SPRING DispatcherServlet은 무엇인가? 본문

Some Memos/Spring 개념

2/28 SPRING DispatcherServlet은 무엇인가?

Flashpacker 2022. 2. 28. 11:50


Reqeust가 들어오면 , 특정 주소 .do라는 주소가 들어오면 frontController에 보내라는 약속의 코드가 web.xml에 있는데

최초의 요청이 왔을떄 URI요청이든 자바파일 요청이 들어오면 바로 자원에 접근을 못한다.

그대신 톰캣에 간다, 톰캣으로 가면 최초에 Reqeust와 Response 객체를 만든다.

 

Request는 어떠한 정보를 가지고 있냐면 요청한 사람의 정보를 들고있다. 요청한 사람의 어떤 데이터를 요청하였는지, 어떤 데이터를 들고 들어왔는지 이런 정보들, 요청한 사람의 정보를 토대로 해서 Response라는 객체를 만든다.

결국은 Request는 나한테 요청한 정보가 들어있고, Response는 내가 응답해줘야되는 객체이다. 

Response에는 내가 응답한 데이터들을 넣어주면되고 Requset에는 나한테 요청이 들어오는 모든 데이터가 들어가 있을것이다.

 이것을 톰캣이 자동으로 만들어준다! 

 

원래는 들어올때는 전부 통신이 BufferedReader, Buffredwriter은 가변길이의 문자가 들어와서 톰캣이 알아서 객체로 만들어준다, 객체로 만들면 머가 좋냐면 자바에서 Requset. 해서 어떤 함수나 변수를 사용할수 있는데 이러한것들을 제공할수 있도록 톰캣이 이 Reuqset, Resppnse 객체 두개를 만든다. 

그리고 Web.xml에서 자기일을 하고 WEb.xml에 JSP Servlet매핑이 너무 많이 들어있으면 복잡하니까 

특정 주소가 들어오면 전부다 특정 주소는 FrontController가 낚아 채라고하면 셋팅을 해놓으면 FronController가 특정 주소르 낚아 챈다.

a.do, b.do와 같은 특정 주소를 낚아 챈다. 

낚아 채서 a.do라는 주소가 들어오면 자원을 찾아갈수 있게 다시한번 Request를 한다. 

Request를 할때는 스프링이는 자원에 접근하지 못하도록 막아놓는다고 했는데 내부에서는 자원 접근이 가능하다.

 

a.do와 b.do 에서 자원에 요청하는것도 다 Reqeust이다 

이 Request가 일어나면 실제로는 메모리에 있는 객체들은 바뀐다 새로운 Requset와 Response로 바뀌는데 어떻게 바뀌냐면 만약에 최초 A라는 사람이 요청을 했으면 메모리에 Reuqest정보와 Response가 만들어지고 이 둘은 A의 정보이다.

근데 A.do를 통해 자원에 새로 Request할때 그 자원 입장에서 Response하는곳은 메모리에 있는곳이 아니라 Froncontroller쪽이다. 그래서 어떤 기법이 필요하냐면 재요청시에 최초 Request와 Response객체가 있는데 

a.do가 자원에 Requset헀을때  이 request정보를 새로 만드는것이 아니라 이전에 있는 Request정보에 덮어씌우는 방법이 있다.

새로 덮어씌우게 되면 기존에 있는 정보는 사라지게되는데 기존에 있던 Request와 Response를 다시 유지하는 방법이 필요한데? 새로운 Reqeust할때 기존에 있는 리퀘스트와 리스판스를 그대로 들고 들어가서 요청할수 있는 방법이 있다.

 

이게 무슨 말이냐면 A와 B가 있으면 웹에서는 요청을 하게되면 응답을 해주는데 

요청시 마다 새로 Request가 만들어지고 응답도 새로 만들어진다. 

한번 요청하고 나서 그 요청한 거에 대한 리퀘스트와 응답 정보가 만들어져있는데 다시 Fontcontroller에서 재요청을 하게되는데 재요청하게되면 Requset와 Response가 새로 만들어져야하는데 그러면 이 A에 대한 정보가 사라지는데 그것을 방지하고자 기존에 있는 Request정보를 유지하는 기법이 있는데..

그게 바로 RequestDispatcher라는걸 이용하는것이다. 

이렇게 되면 기존에 있는 리퀘스트와 리스판스는 사라지지않고 재사용이 가능하다. 

 

그래서 최초 앞단에서 Request 요청을 받아서 필요한 클래스에 넘겨준다 왜냐하면 Web.xml에 다 정의하기가 너무 힘드니까 이떄 새로운 요청이 생기기 떄문에 Request와 response가 새롭게 new가 될수 있기 때문에 그래서 RequestDispatcher가 필요하다! 

이 RequestDispatcher의 역할은? 필요한 클래스 요청이 도달했을때 FrontController에 도착한 Request와 Response의 정보 를 그대로 유지시켜주는 기법이다. 

 

이걸 언제 많이 쓰냐면 만약에 어떤 A라는 사람이 A.jsp라는 파일을 요청하면 응답을 A.jsp 파일을 a.html로 응답을 해준다. A라는 사람은 웹 브라우저를 요청했기 떄문에 웹브라우저 화면에 보면 A.html이 있을것이다. 

그떄 이 a.jsp에 요청에대한 Request와 Response객체가 만들어졌을것이다. 이거를 이 화면에서 어떤 버튼을 클릭했을때 다음페이지로 가게 새로운 요청을 할수 도 있다. a에서 b.jsp로 갈게 b.jsp에대한 b.html을 응답해줄것이고

우리는 b.html을 보게 될것이다. 

근데 이 b.html에서는 a.html에서 들고 있는 어떤 데이터 , 이 화면에서 들고 있는 데이터는 전부다 Request와 response가 들고 있다. 새로운 요청이 일어나니까 이 Request와 response는 사라지는데 이걸 안사라지기 위해 새로운 요청시에 RequsetDispatcher방식을 이용하면 b에서 기존에 A에서 만들어졌던 이 Requset와 Response를 그대로 b.html에서 사용할수 있다. 

 

그러면 이 Request가 만약에 a라는 데이터를 가지고 있다면 a라는 데이터를 그대로 b에서도 유지할 수 있다. 

왜냐하면 b에서 요청한 Request는 새로운 Request가 아니라 기존에 있는 Request를 재사용하기 때문이다. 

이 RequestDispatcher를 이용해야지 페이지간 데이터 이동이 가능하다! 

데이터를 들고 페이지를 이동할수있는 기법이 RequestDispatcher이다! 

 

 

이 RequsetDispatcher와 FrontController패턴을 두개를 묶은것을 스프링에서 제공해주는 DispatchServlet 이 있다.

애를 사용하면 FrontController 패턴을 짜거나 RequestDispatcher을 직접 구현할 필요가 없다. 왜냐하면 스프링에는 DispathServlet이 있기 떄문이다. DispatchServlet은 FronController 패턴과 RequesTdispatcher의 모음이다.

 

DispatchServlet이 자동생성 되어 질때 수많은 객체가 IOC로 생성이 된다. 이게 보통 필터틀이다. 해당 필터 혹 객체들, 컨트롤러, 리파지토리, 서비스 , 컨피규레이션, 빈, 컴포넌트가 자동 등록되어진다!