Spring Web MVC

백기선님의 강의인 Spring Web MVC 강의를 듣고 공부한 내용을 정리한 글

스프링 부트의 MVC 설정

일일이 MVC 설정을 해야하는 Spring MVC와는 달리, 스프링 부트에서는 Spring MVC의 설정을 자동으로 지원해주고 있다.

handlerMapping과 handlerAdapter가 기존 MVC보다 부트에서 더 많이 설정되어 있는 것을 확인할 수 있다.

SimpleUrlHandlerMapping에는 resourceHandlerMapping이라는 빈이 등록되어있는데, 이 빈 덕분에 static 폴더에 존재하는 정적 파일들을 사용할 수 있게 되는 것이다.

static 파일들에 resourceHandlerMapping을 적용하면 캐싱 관련된 정보가 응답 헤더에 추가된다.

그래서 리소스를 조금 더 효율적으로 처리할 수 있는데, 가령 새로고침을 했을 때 변경사항이 없으면 notmodified라는 응답을 보내서 브라우저가 캐싱하고 있는 리소스를 그대로 사용하도록 하는 처리 또한 가능하다.

viewResolvers에는 ContentNegotiatingViewResolver를 비롯한 리졸버들이 등록되어있는데, 사실상 ContentNegotiatingViewResolver가 다른 뷰 리졸버들에게 Delegate하기 때문에 사실상 본체라고 보면 된다.

ContentNegotiatingViewResolver는 자기가 직접 뷰를 찾지않고 자신이 참조하고 있는 다른 뷰 리졸버에게 작업을 위임한다.

즉, ContentNegotiatingViewResolver가 다른 뷰 리졸버들을 참조하고 있다는 얘기이다.

요청 정보에서 어떠한 뷰를 원하는 것인지 분석해서 다른 뷰 리졸버가 찾아낸 뷰 중에 ContentNegotiatingViewResolver가 가장 적절한 뷰를 내려준다.

그렇기 때문에 ContentNegotiatingViewResolver는 우선순위가 가장 높다.

스프링 부트 MVC 설정 커스터마이징

스프링 부트에서는 autoconfigure라는 의존성에 spring.factories를 보면 자동 설정이 될 수 있는 빈들의 리스트가 존재한다.

여기를 보면 WebMvcConfiguration 클래스가 존재하는데 이 클래스의 애노테이션들 중 @ConditionalOnWebApplication라는 애노테이션이 존재한다.

이 애노테이션은 스프링 부트 애플리케이션이 특정 상태일 경우 빈으로 등록한다는 설정이다.

참고로 스프링 부트 애플리케이션의 상태는 총 3가지이다. Servlet, Webflux, NonWeb 이렇게 세 가지이다.

기본적으로는 상태의 타입이 SERVLET인 경우에 해당 빈이 등록된다. (Webflux라면 다른 설정 빈이 등록될 것이다.)

그리고 @ConditionalMissingBean이라는 애노테이션이 존재하는데 이 애노테이션은 WebMvcConfigurationSupport 빈이 등록되지 않은 경우에만 사용할 수 있다는 애노테이션이다.

WebMvcConfigurationSupport는 이전 시간에 살펴보았다.

@EnableWebMVC 애노테이션이 import하는 DelegatingWebMvcConfiguration이 상속받고 있는 클래스이다.

그래서 결국 WebMvcConfiguration는 위의 조건을 만족하는 경우에만 사용한다는 뜻이다.

즉, 만약 스프링 부트가 지원하는 Spring MVC 설정을 나는 사용하고 싶지 않다! 라고 한다면

@Configuration + @EnableWebMvc

를 사용하면 스프링 부트 설정을 사용하지 않을 수 있다.

또는 기존 스프링 부트의 MVC 설정을 그대로 가져가면서 추가하고 싶은 경우라면

@Configuration + Implements WebMvcConfigurer로 사용하면 된다.

또 다른 방법으로는 application.properties를 사용해서 Spring MVC 설정을 커스터마이징 하는 것 또한 가능하다.

Reference

인프런 백기선님의 스프링 Web MVC