2021-06-23글
[10분 테코톡] 🐶 코기의 Servlet vs Spring을 들으며 정리한 글입니다.
서블릿이란
- 처음 웹 서버는 정적인 페이지만 만들 수 있었음
- 웹서버에 프로그램을 붙여 동적인 페이지를 생성하기 시작
- 서블릿이 이 프로그램 중 하나
- 서블릿은 동적인 페이지를 만드는 프로그램 중 하나이다.
서블릿으로 요청을 처리하는 방법
- 서블릿은 이런 HTTP 요청과 응답을 좀 더 쉽게 다룰 수 있는 메서드(기능)을 제공
- 개발자들이 집중해야하는 비즈니스 로직에 집중할 수 있음
service(): 요청을 처리할 때 수행하는 메서드
- 개발자가 처리하고 싶은
doXxx()를 재정의해주자! - 서비스 메서드만 재정의해서 처리 방법을 지정
서블릿 컨테이너와 서블릿이 호출되는 과정
- 서블릿 컨테이너는 서블릿을 관리하는 친구 (생명주기 관리)
사용차 요청이 들어오면
- Servlet Request / Servlet Response 객체 생성
- 설정 파일을 참고하여 맵핑할 Servlet을 확인
- 해당 서블릿 인스턴스 존재 유무를 확인하여 없으면 생성
init() - Servlet Container에 스레드를 생성하고 res, req를 인자로 service 실행
- 응답을 처리한 Servlet Request / Servlet Response 객체 소명
서블릿은 싱글톤이기 때문에 소멸되지 않고 관리된다.
참고 - 설정 파일
한 요청을 처리하는 도중 다른 요청이 들어오면?
- 멀티 스레드로 요청을 처리
- 스레드당 다른 요청을 처리하거나
- 여러 스레드에서 한 서블릿의 여러 요청을 동시에 처리
- 하지만 스레드는 생성비용이 비싸고, 다른 스레드로 전환하는 것이 많은 오버로딩을 일으킴
요청당 서블릿을 정해주면 비효율적이다.
- 관리적인 측면에서는 멀티스레딩을 다뤄야하는 어려움
- 개발적인 측면에서는 핸들러의 공통 로직이 매번 중복됨
핸들러의 공통 로직 중복?
- 주문, 계산, 포장이 중복됨
- 손님의 요청을 처리하는 과정 중 중복되는 로직을 앞단에 매니저를 두는 것이 컨트롤러 패턴
Dispatcher Servlet
- 이전에는 요청마다 서블릿을 정의하고 수행할 때마다 스레드를 처리하는 로직을 수행했다면
- 이제는 하나의 서블릿만 정의하고 이 서블릿이 모든 요청을 수행할 수 있도록 하는 전략을 따름
Dispatcher Servlet이 web 요청을 처리하는 과정
- 전면 매니저가 모든 요청을 처리는 하되,
- 각각 담당 직원을 둠
- DispatcherServlet이 모든 요청을 받음
- 핸들러 맵핑이라는 애가 내 요청을 처리할 때 컨트롤러를 찾아서 반환
- 핸들러 어댑터는 해당 컨트롤러 메서드를 호출하여 처리로직 수행하는 역할
- 처리 결과를 Model And View 객체로 변환하여 DispatcherServlet에 넘김
- DispatcherServlet은 뷰 리졸버를 이용해 뷰를 찾거나 생성
- 이렇게 얻은 뷰에 얻은 데이터를 넣어 응답 객체 생성
스프링을 사용하면 개발자는 핸들러만 신경써주면 된다.
핸들러 매핑과 핸들러 어댑터 뷰 리졸버는 DispatcherServlet이 스프링 컨테이너로부터 주입을 받아서 사용하고 동작
스프링 컨테이너
- 프로그램이 동작한느 동안 사용되는 자바 객체들을 프레임워크가 대신 관리하고 보관하기 위해 사용되는 바구니
Servlet WebApplicationContext
- 웹 요청 처리 관련 객체들이 담겨있음
Root WebApplicationContext
- 웹 요청 처리 관련된 빈 외의 컴포넌트들 (서비스, 레포지토리 등)
서블릿 설정 파일만 잘 작성해주면 설정대로 생성된 객체가 스프링 컨테이너에서 관리되고 필요한 부분에서 주입받아 Dispatcher Servlet이 알아서 사용할 수 있게된다.
스프링으로 웹 요청을 처리한다는 것은
- 스프링 mvc 에서 제공하는 Dispatcher Servlet과 웹 요청 처리 관련 구현체들을 사용할 수 있음
- 동시에 스프링 컨테이너, 즉 스프링 IoC를 사용해서 개발할 수 있음
- 즉 개발자는 핸들러에만(컨트롤러) 집중할 수 있도록!
