서블릿 애플리케이션 (스프링 MVC - 2)

1. 서블릿 애플리케이션

 

서블릿

- 자바EE는 웹 애플리케이션 개발용 스펙과 API를 제공

- 요청 당 쓰레드를 만들거나, 풀에서 가져다가 사용 

- HttpServlet

 

서블릿 장점

- 빠르다

- 플랫폼 독립적

- 보안

- 이식성

 

서블릿 컨테이너

- 톰켓, 제티, 언더토

- 서블릿 스펙(웹 애플리케이션 개발 스펙과 API)을 준수하는 것들

- 세션 관리 

- 네트워크 서비스

- 서블릿 생명주기 관리 (init, destroy)

 

 

2. 서블릿 리스너와 서블릿 필터

 

서블릿 리스너

- 웹 애플리케이션에서 발생하는 주요 이벤트를 감지하고 각 이벤트에 특별한 작업이 필요한 경우에 사용할 수 있다.

- 서블릿 컨텍스트 수준의 이벤트, 세션 수준의 이벤트

 

서블릿 필터

- 들어온 요청을 서블릿으로 보내고, 또 서블릿이 작성한 응답을 클라이언트로 보내기 전에 특별한 처리가 필요한 경우에 사용할 수 있음

- 체인 형태의 구조

 

 

3. 서블릿에서 스프링에서 제공하는 IoC 컨테이너 연동하기

 

1) spring-mvc 의존성 추가

 

2) ContextLoaderListener 추가

- Application Context를 만듬.

- 서블릿 생명주기에 맞추어 Application Context가 실행되도록 함

 

3) 스프링 설정 파일 생성 및 위치 설정

- Application Context를 만들기 위해서는 스프링 설정 파일 필요

 

 

4. 서블릿에 스프링 MVC 적용하기

 

Servlet에서는 각 url 마다 서블릿을 매핑해줘야 함 -> 설정 코드가 길어지고 불편

따라서, 모든 요청을 FrontController가 받고, 핸들러에게 dispatch하는 방식으로 해결 가능

스프링이 이러한 것을 구현했음 (DispathcherServlet - 스프링MVC에서 가장 핵심적인 클래스)

 

웹 설정 없는 Application Context와 웹 설정이 들어간 Application Context 를 계층적으로 구현함

Service 와 같은 것은 모든 곳에서 사용 가능하도록 하기 위해

(경우에 따라 설정하는 것으로, 굳이 계층적으로 구현하지 않고 모든 설정이 들어가도록 해도 됨 -> 최근에는 더더욱 계층적으로 구현하지 않음)

 

(계층적으로 구현하지 않는다면 위의 3번 과정 삭제 후 진행)

1) DispathcherServlet 을 추가

2) 위와 같이 설정 파일 생성 및 위치 설정

3) 서블릿 매핑 설정 (/app/*)

4) Controller 작성

 

 

스프링 부트와 다른 점

- 이러한 방식은 서블릿 컨테이너가 먼저 작동하고 서블릿 애플리케이션이 동작

- 스프링 부트는 스프링 부트 어플리케이션이 먼저 작동하고, 내부적으로 서블릿 컨테이너가 동작

 

 

5. DispatcherServlet

 

HandlerMapping : 핸들러를 찾아주는 인터페이스

HandlerAdapter : 핸들러를 실행하는 인터페이스

HandlerExceptionResolver

ViewResolver

 

동작 순서

1. 요청을 분석한다. (로케일, 테마, 멀티파트 등)

2. (핸들러 매핑에게 위임하여) 요청을 처리할 핸들러를 찾는다.

3. (등록되어 있는 핸들러 어댑터 중에 ) 해당 핸들러를 실행할 수 있는 "핸들러 어댑터"를 찾는다.

4. 찾아낸 "핸들러 어댑터"를 사용해서 핸들러의 응답을 처리한다.

   4-1) 핸들러의 리턴 값을 보고 어떻게 처리할 지 판단한다.

     - ViewResolver가 뷰 이름에 해당하는 뷰를 찾아서 모델 데이터를 랜더링한다.

     - @ResponseEntity가 있다면 Converter를 사용해서 응답 본문을 만든다.

5. (부가적으로) 예외가 발생했다면, 예외 처리 핸들러에 요청 처리를 위임한다.

6. 최종적으로 응답을 보낸다.

 

 

6. 스프링 MVC (DispatcherServlet) 구성요소

 

스프링 MVC = 결국엔 (굉장히 복잡한) Servlet = DispatcherServlet

 

초기화 시에

다음과 같은 구현체의 빈이 없으면

스프링이 기본으로 사용하는 전략을 사용함 (DispatcherServlet.properties에 명시되어 있음)

 

MultipartResolver

- 파일 업로드 요청 처리에 필요한 인터페이스

- 스프링 부트를 사용할 경우 빈 등록 없이 바로 사용 가능

 

LocaleResolver

- 클라이언트의 위치 정보를 파악하는 인터페이스

- 기본 전략은 요청의 accept-langugage를 보고 판단

 

ThemeResolver

- 애플리케이션에 설정된 테마를 파악하고 변경할 수 있는 인터페이스

 

HandlerMapping

- 요청을 처리할 핸들러를 찾는 인터페이스

 

HandlerAdapter

- HandlerMapping이 찾아낸 '핸들러'를 처리하는 인터페이스

- 스프링 MVC의 확장력의 핵심

 

HandlerExceptionResolvers

- 요청 처리 중에 발생한 에러를 처리하는 인터페이스

 

RequestToViewNameTranslator

- 핸들러에서 뷰 이름을 명시적으로 리턴하지 않은 경우, 요청을 기반으로 뷰 이름을 판단하는 인터페이스

 

ViewResolver

- 뷰 이름에 해당하는 뷰를 찾아내는 인터페이스

 

FlashMapManager

- FlashMap 인스턴스를 가져오고 저장하는 인터페이스

- FlashMap은 주로 리다이렉션을 사용할 때 요청 매개변수를 사용하지 않고 데이터를 전달하고 정리할 때 사용한다.

 

 

7. 비교

 

스프링 부트 사용하지 않는 스프링 MVC

- 서블릿 컨테이녀에 등록한 웹 애플리케이션에 DispatcherServlet을 등록함.

- 세부 구성 요소는 빈 설정하기 나름

 

스프링 부트 사용하는 MVC

- 자바 애플리케이션에서 내장 톰캣을 만들고 그 안에 DispatcherServlet을 등록함

       -> 스프링 부트 자동 설정이 자동으로 해줌

- 스프링 부트의 주관에 따라 여러 인터페이스 구현체를 빈으로 등록함.

 

=> 스프링 부트가 스프링 MVC를 편하게 사용하도록 함

 

 

8. 스프링 MVC 커스터마이징

- application.properties : 가장 손을 안대고 추가 설정 가능

- @Configuration + Implements WebMvcConfigurer : 스프링 부트의 스프링 MVC 자동설정 + 추가 설정

- @Configuration + @EnableWebMvc + Implements WebMvcConfigurer : 스프링 부트의 스프링 MVC 자동설정을 사용하지 않음

 

 

 

인프런 백기선님 '스프링 MVC’ 강의를 듣고 정리한 내용입니다.