-
서블릿 : 동적 페이지를 만들기 위해 웹서버에 붙이는 프로그램 중 하나
-
서블릿이 요구하는 구현 규칙을 지켜주면서 서블릿을 정의해주면 http 요청 정보를 쉽게 사용할 수 있고 처리 결과를 쉽게 응답으로 변환할 수 있음
-
처리하고 싶은 doXXX메소드 재정의만 하면 됨
-
즉 서비스 메소드만 재정의해서 처리 방법을 지정하면 됨
-
서블릿 컨테이너 : 서블릿 담고 관리
사용자 요청 -> 서블릿 컨테이너는 해당 요청과 매핑된 서블릿을 찾음(설정 파일에 정의) -> 서블릿 인스턴스가 컨테이너에 있는지 확인(없으면 생성해서 가져가 사용) -> 서블릿 컨테이너의 스레드 생성 -> 미리 만든 HttpServletResponse랑 HttpServletRequest 객체를 인자로 서비스를 호출 -> Request와 Response 소멸 -> 서블릿은 싱글톤으로 소멸하지 않고 다음 요청을 기다림
-
요청이 여러개가 되면 멀티스레드로 처리
-
스레드 생성 비용이 높음, context switch 많은 오버헤드 일으키기에 주의
-
스레드 생성 제한 하지 않으면 서버의 하드웨어 성능 넘어버리면 서버 터질수도 있음
-
요청당 서블릿을 정해주는 곳에는 비효율적인 부분이 있었다.
(관리 : 멀티스레딩을 다뤄야 하는 어려움, 개발 : 핸들러의 공통 로직이 매번 중복) -
프론트 컨트롤러 패턴 : 요청을 앞단에서 처리할 수 있는 일을 전담하는 매니저를 두는 것
-
스프링 MVC도 프론트 컨트롤러 패턴을 따르고, 모든 요청을 받는 전면 컨트롤러(Dispatcher Servlet)
--> 하나의 서블릿만 정의하고 그 서블릿을 모든 요청을 수행할 수 있도록 하는 전략 -
디스패처서블릿 : 모든 요청을 다 받고
-
핸들러매핑 : 요청을 받고 컨트롤러를 찾아서 반환
-
핸들러어댑터 : 컨트롤러의 메서드를 호출하여 처리 로직을 수행하는 역할
-> 처리 결과를 모델 앤 뷰 객체로 변환해서 디스패처 서블릿으로 넘김
-> 뷰 리졸버를 이용해서 뷰를 찾거나 생성
-> 모델로 들어왔던 데이터를 넣어서 응답결과 생성 요청
-> JSP나 타임리프 같은 데이터를 담은 출력 파일로 응답 -
스프링 웹 요청 처리 : 스프링 mvc에서 제공하는 디스패처서블릿과 웹 요청 처리 관련 구현체들을 사용할 수 있다는 이야기와 동시에 스프링 컨테이너(스프링 IoC)를 사용해서 개발할 수 있음
-
개발자로 하여금 핸들러(요청처리 로직)만 구현할 수 있도록 하기 위함
