[Spring] Spring in Action, Chapter 5. 스프링 웹 애플리케이션 만들기

Web 기반 Appl.의 경우 state 관리, workflow, 검증은 매우 중요하게 고려되어야 할 사항이지만, HTTP protocol의 stateless 성격을 감안했을 때 쉽게 해결되지 않음.

스프링 Web FWK는 이런 문제들을 처리하는 데 도움을 줄 수 있도록 디자인되어있음. MVC 패턴을 기반으로 스프링 MVC는 스프링 FWK 자체와 긴밀한 연결없이 유연한 Web 기반 Appl.을 만드는 데 도움을 줌.

 

Request, Dispatcher Servlet, Handler Mapping, Controller, View Resolver 등

 

< Spring MVC를 이용한 요청 추적>

DispatcherServlet

• 요청을 스프링 MVC Controller에 전달해 주는 것. (Controller는 요청을 처리하기 위한 스프링 component)
• But, 일반적으로 Appl.은 여러 개의 Controller를 가지고 있어서 DispatchServlet은 요청을 전달할 component를 선택하기 위한 도움이 필요함. → Handler Mapping

 

Handler Mapping

• DispatcherServlet으로 부터 도움을 요청 받은 Handler Mapping은 결정을 내릴 때 요청이 가져온 URL에 특별히 주목함.

 

DispatcherServlet

• Handler Mapping의 도움으로 적당한 Controller가 선택되면, 선택된 Controller에 요청을 보냄.
• Controller에서 요청은 Payload(사용자에 의해 입력된 정보)를 떨굼. 그 후 Controller가 그 정보들을 처리하는 시간을 기다림.

 

Controller

• DispatcherServlet으로 부터 받은 Payload 정보를 처리함.
• 처리된 logic의 결과는 사용자의 브라우저에 표시되기 위한 형태의 정보로 반환됨 → 이 정보를 일반적으로 모델이라고 함.
• But, 이러한 정보들은 그냥 사용자에게 반환하는 것은 효과적인 방식이 아님.
• 그리하여 HTML과 같이 사용자 편의성을 갖춘 형태로 전환함. 이를 위해 정보들에게는 JSP(JavaServer Page) 같은 View를 필요로 함.
• 마지막으로 Model을 packing하는 일과 결과물을 rendering하기 위한 view의 이름을 확인함. 그런 다음 Model과 View 이름을 포함하여 DispatcherServlet에게 요청을 돌려보냄.
  ※ Controller는 특정 view와의 긴밀성을 갖지 않고, DispatcherServlet에 전달된 view의 이름은 직접적으로 특정 JSP를 의미하지 않게 됨.

 

DispatcherServlet

• ViewResolver에게 논리적으로 주어진 View의 이름과 실제로 구현된 뷰를 mapping해줄 것을 요청함. (구현된 뷰는 JSP일 수도 있고 아닐 수도 있음)

 

ViewResolver

• 논리적으로 주어진 View의 이름과 실제로 구현된 뷰를 Mapping함.

 

DispatcherServlet

• 결과를 rendering하기 위한 view가 어떤 것인지 정보를 ViewResolver로 부터 확인받음.
• 요청의 마지막 여정은 일반적으로 JSP로 model data를 전달해주는 View의 구현으로 끝이 남.
  
  

View

• Model data를 사용하여 결과를 rendering하고 Response 객체에 의해 클라이언트로 전달됨.