진짜 개발자
본문 바로가기

FrameWork/Spring MVC

SpringMVC - Spring MVC 동작원리 - 6 (DispatcherServlet의 구성요소)

728x90
Spring MVC 구성요소

Spring MVC의 구성요소들에 대해서 살펴보겠습니다.

 

우선 위의 그림은 DispatcherServlet이 Web환경을 제공하기 위해 사용하는 여러 Interface들입니다. 각각의 것들을 조금 더 자세히 알아보도록 하겠습니다.

 

 

 

1. MultipartResolver

MultipartResolver의 경우 사용자의 파일업로드 요청에 대한 처리를 하는 인터페이스입니다. HttpServletRequestMultipartHttpServlerRequest로 변환해 getFile() 메소드를 통해 요청에 담긴 file을 쉽게 꺼낼 수 있는 API를 제공합니다.

 

MultiparResolver의 경우에는 개발자가 별도의 Bean을 등록하지 않는다고해도 별도로 Spring에서 등록해주지 않습니다. 즉, Default 값이 null입니다. 하지만 Spring Boot를 사용한다면 기본 구현체가 등록이 됩니다. Spring을 알아보는 시간 이므로 더 자세한 내용은 생략하겠습니다.

 

중요한 것은 SpringMVC에서 파일업로드 처리를 하고 싶다면 DispatcherServlet에서 사용할 MultipartResolver의 Bean을 등록을 해주어야합니다.

 

 

2. LocalResolver

요청하는 사용자의 Client의 Locale 정보를 파악하는 인터페이스 입니다. 기본전략으로는 사용자 요청의 accept-language를 보고 판단하는 AcceptHeaderLocaleResolver가 사용이됩니다.

 

MultipartResolver와는 다르게 개발자가 등록한 별도의 Bean이 없는 경우 getDefaultStrategy()메소드를 통해 기본전략의 구현체를 등록해주게 됩니다. 어떠한 구현체가 기본으로 등록되는지 알아보겠습니다.

 

이전 시간의 ViewResolver 포스팅에서 개발자가 등록한 Bean이 없을때 defaultStrategies라는 곳에 Inteface의 이름을 key값으로해 구현체 Class의 이름을 가져온다고 했었습니다. 이곳에 가면 LocalResolver의 기본전략 구현체를 알 수 있을 것입니다. defaultStrategies를 따라와 보니 DEFAULT_STRATEGIES_PATH라는 상수에 파일의 경로가 적혀있는것 같습니다.

 

Shift를 두번 누르면(Intelli J IDE 기준) 다음과 같이 검색할 수 있는 창이 나타납니다. 여기에 방금 알아낸 파일의 경로를 적어주고 처음에 나타나는 파일을 클릭합니다.

 

앞서 말씀드렸듯이, LocaleResolver의 경우에는 AcceptHeaderLocaleResolver를 기본 전략 구현체로 사용하는 것을 알 수 있습니다.

 

 

3. ThemeResolver

TehemeResolver는 어플리케이션의 테마를 변경할 수 있도록 하는 인터페이스 입니다. 간단히 예를 들자면dark.css , white.css 이러한 두가지 css를 만들어 놓고 사용자가 dark테마를 클릭했을때에는 어플리케이션에 dark.css적용해 반환하고, white 테마를 클릭하면 white.css를 적용해 반환해주는 등의 일을 합니다.

 

 

4. HandlerMapping

이전 포스팅에서 자세히 다루었으므로 간단히 설명만 드리겠습니다. HandlerMapping의 경우 사용자가 요청한 url을 분석하여 이것을 처리할 handler를 찾아주는 역할을 하게 됩니다. 기본적으로 DispatcherServlet에 등록되어있는 2가지 Handler가 있으며, @을 기반으로 API를 작성했다면 RequestMappingHandlerMapping구현체가 사용이 됩니다.

 

 

5. HandlerAdapter

HandlerMapping이 찾아낸 handler를 호출하고 처리하는 인터페이스 입니다. 즉, 요청을 처리하는 역할을 합니다. HandlerAdapter도 DispatcherServlet에서 기본적으로 등록해주는 구현체들이 있습니다. @을 기반으로 API를 작성했다면 RequestMappingHandlerAdapter구현체가 사용됩니다. 이것 역시 이전 포스팅에서 자세히 알아보았으므로 생략하겠습니다.

 

 

6. HandlerExceptionResolver

요청 처리중 발생한 에러를 처리하는 인터페이스 입니다.

 

 

 

7. RequestToViewNameTranslator

사용자의 요청을을 보고 요청에 대응하는 view를 찾아내는 인터페이스 입니다.

 

위와 같이 handler에서 반환하는 값이 없는 상황에서, 요청 url인 /sample에 대응하는 sample.jsp 를 알아서 찾아서 반환해주는 역할을 하게됩니다.

 

잘 응답하는 것을 볼 수 있습니다. 이렇게 요청을 보고 view의 이름을 추측해 적당한 view를 응답할수 있게 해주는 역할을 하는것이 RequestToViewNameTranslator입니다.

 

 

8. ViewResolver

handler에서 반환하는 View 이름(String)에 해당하는 View를 찾아내는 인터페이스 입니다. 개발자가 별도의 Bean을 등록하지 않는다면, 기본전략으로 InternalResourceViewResolver가 사용이됩니다. InternalResourceViewResolver는 기본적으로 JSP를 지원하기 때문에 지금까지 JSP를 사용하여 반환할 수 있었던 것입니다. 이것 역시 이전 포스팅에서 자세히 알아보았으므로 넘어가겠습니다.

 

 

9. FlashMapManager

필요에 의해 Redirect를 할 때에 데이터를 손쉽게 전달할때 사용합니다.

즉, Redirect시 데이터를 전달할때에는 파라미터를 이용해 전달합니다(http://example?a=1&b=2). 이때, url이 굉장히 복잡해지고, url의 길이제한에 걸릴 수도 있습니다. 즉 이런 경우에 FlashMap을 복원한다면 redirect 될때 단한번만 값을 유지하도록 할 수 있습니다.