2021.08.08 기록장

ToDo

• 알고리즘 문제
• 토비의 스프링

Done

• 토비의 스프링

Weekly goal

• 책 읽기
• 토비 스프링 코딩
• 7월 회고 쓰기

토비의 스프링

 

358p.

스프링은 2개의 컨텍스트로 이뤄진다고 했다. 서비스 계층과 데이터 액세스 계층을 가지고 있는 루트 컨텍스트, 웹 관련 빈을 담당하는 웹 애플리케이션 컨텍스트이다. 

스프링 mvc에서는 프론트 컨트롤러로 디스 패쳐 서블릿을 사용하는데 이는 빈이 아니라 오브젝트이다. 내부에서 루트 컨텍스트를 사용한다.

요청 순서를 살펴보면

 

1. 디스 패쳐 서블릿이 http요청을 받는다. 자신이 받겠다고 정의한 url의 요청을 받는다.

 

2. 디스패쳐 서블릿은 컨트롤러로 http요청을 위임한다. 컨트롤러를 정하는 방법은 핸들러 매칭 전략을 사용한다. 

어떤 컨트롤러가 처리할지 정해지면 해당 컨트롤러의 메서드를 실행시켜야 하는데 어느 메서드를 실행시킬지는 알지 못한다. 그래서 중간에 어댑터를 둬서 호출한다. 그럼 일정한 방식으로 컨트롤러를 호출할 수 있게 된다.

어댑터는 컨트롤러에게 결괏값을 받아서 디스 패쳐 서블릿에게 다시 돌려준다.

 

3. 컨트롤러의 결괏값에는 모델과 뷰가 있어야 한다.

 

4. 뷰는 모델과 달리 오브젝트로 주지 않고 논리적인 이름으로 전해준다. 그럼 디스 패쳐 서블릿은 전략 중 하나인 뷰 리졸버를 통해 뷰 오브젝트를 생성한다.

 

5. 어댑터를 통해 컨트롤러의 메서드 결과물인 모델과 뷰를 받았다. 그럼 디스 패쳐 서블릿은 뷰 오브젝트에게 모델을 전달하고 결과물을 생산하는 것이다.

 

6. 뷰 생성까지 끝났으면 디스 패쳐 서블릿은 반환할 준비를 한다. 후처리기가 있는지 확인하고 없으면 뷰가 만들어준 httpServletResponse에 담긴 최종 결과를 서블릿 컨테이너에게 돌려준다. 컨테이너는 httpServletResponse에 담긴 정보를 http응답으로 만들어 사용자에게 반환한다.

 

 

디스패처 서블릿은 기본 전략들을 DispatcherServlet.properties라는 전략 설정 파일로부터 가져와서 초기화를 한다.

디스패처 서블릿은 서블릿 컨테이너가 관리하는 오브젝트이지 스프링 컨텍스트에서 관리하는 빈 오브젝트가 아니다.

그래서 직정 DI설정을 해줄 수 없고 내부에서 서블릿 웹 애플리케이션 컨텍스트를 가지고 있고, 이를 통해 빈을 가지고 온다.

지금은 모든 요청을  디스패쳐 서블릿. 정적 자원 요청은 컨트롤러에서 정의한 것이 없으니 컨트롤러를 찾다가 정적 자원을 찾으러 간다.

 

https://taes-k.github.io/2020/02/16/servlet-container-spring-container/

 

https://velog.io/@16616516/%EC%84%9C%EB%B8%94%EB%A6%BF-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88%EC%99%80-%EC%8A%A4%ED%94%84%EB%A7%81-%EC%BB%A8%ED%85%8C%EC%9D%B4%EB%84%88

서블릿 컨테이너와 스프링 컨테이너

https://mangkyu.tistory.com/18

[Spring]Dispatcher-Servlet(디스패처 서블릿)이란?

서블릿 컨테이너는 사용자의 요청을 받아서 HttpServletRequest와 ~~ Response를 준다. 또 Http세션, ServletContext, 쿠키, 헤더 등을 오브젝트 형태로 제공해준다.

 

https://taes-k.github.io/2020/02/16/servlet-container-spring-container/

Tomcat, Spring MVC의 동작 과정