12.Spring, 스프링MVC의 핵심개념 중 뷰(View) 리솔루션 에 대해서 알아볼께요.

스프링MVC 에서 뷰(View) 리솔루션에 대해서 알아보자

• 스프링MVC에서 View 는 웹 애플리케이션 컨텍스트에 하나 이상 선언된 뷰 리졸버 Bean을 해석함.
  • 즉, 뷰 리졸버 Bean 은 DispatcherServlet 이 자동 감지 할 수 있도록 ViewResolver 인터페이스를 구현해야함.
• 스프링MVC는 매우 유연한 뷰 리솔류션을 제공함.
  • 주요 다중 뷰 분석 전략
    • InternalResourceViewResolver
      • 템플릿의 이름과 위치에 뷰를 직접 매핑하는 뷰 리솔루션
    • XmlViewResolver
      • 외부 XML 구성을 기반으로 한 뷰 리솔루션
    • ResourceBundleViewResolver
      • XML 구성파일말고 리소스 번들에 뷰 Bean을 선언하는 뷰 리솔루션
    • ContentNegotiatingViewResolver
      • Accept 요청 헤더를 기반으로 다른 뷰 리졸버로 위임하는 뷰 리솔루션

그럼, InternalResourceViewResolver 에 대해서 알아볼까요?

• InternalResourceViewResolver 는 prefix/suffix을 이용해 뷰 이름을 특정 애플리케이션 디렉토리에 대응시킴.
  • 그럼, InternalResourceViewResolver 을 등록하려면 어떻게 해야 할까?
    • 정답
      • 아래와 같이 웹 애플리케이션 컨텍스트에 해당 타입의 Bean 을 선언함.

• 이해가 쉽도록, 예를 한가지 들어보자
  • 만약 thubhello 라는 뷰 이름이 있다면, InternalResourceViewResolver 는 아래와 같이 해석하게됨.
    • thubhello 
      • /WEB-INF/jsp/thubhello.jsp
  • 그리고, 해석된 뷰 타입은 viewClass 프로퍼티로 지정할 수 있음.
    • InternalResourceViewResolver 는 classpath에 JSTL 라이브러리(jstl.jar)가 있으면, 기본적으로 JstlView형 뷰 객체로 해석하게 되어 있음.
      • 즉, JSTL 태그가 포함된 JSP 템플릿 형태의 뷰는 viewClass를 생략해도 됨.
  • 그럼 단점은 ?
    • RequestDispather가 포워딩할 수 있는 내부적인 리소스뷰만 해석할 수 있음.
      • 즉, 내부 JSP 파일 or 서블릿
    • 즉, 스프링 MVC에서 다른 뷰 타입까지 지원하려면 다른 해석 전략을 사용해야 함.

그럼, XmlViewResolver에 대해서 알아볼까요?

• 뷰를 스프링 Bean 으로 선언 후 해당 Bean 이름으로 해석하는 전략.
• 보통은, 웹애플리케이션 컨텍스트와 같은 구성 파일에 뷰 빈을 같이 선언하지 않고, 별도 파일로 빼는것을 권장함.
• 그리고, XmlViewResolver 은 디폴트로 아래 파일에서 뷰 Bean을 읽어옴.
  • /WEB-INF/views.xml
  • but, 위치설정으로 위치를 변경할 수 도 있음.
• 예시

XML 구성파일

• tuser-view.xml

• 설명
  • 각 뷰를 일반 스프링 Bean으로 선언함.

그럼, ResourceBundleViewResolver에 대해서 알아볼까요?

• ResourceBundleViewResolver 는, XML 구성 파일대신, 리소스 번들에 뷰 Bean을 선언하는 방법임.
• ResourceBundleViewResolver는 classpath root에 있는 리소스 번들에서 뷰 Bean을 읽어들임.
  • 로케일 별로 리소스 번들을 따로따로 로그할 수 있음.
• 예시

설명

• 예를들면,
  • ResourceBundleViewResolver 의 베이스 이름을 tuser-views 라고 지정하면,
  • 리소스 번들은 아래 파일이 됨
    • 예시
      • tuser-views.properties 

• 설명
  • 해당 리소스 번들에 뷰 Bean을 프로퍼티 형식으로 선언하면 XML파일에 Bean 선언을 할때와 내용은 별 차이가 없음.

• 그럼, ContentNegotiatingViewResolver에 대해서 알아볼까요?

  • ContentNegotiatingViewResolver 는 View 를 찾기위해 요청 URL의 확장자와 HTTP 의 Accept 헤더를 사용하는 ViewResolver임.

    • 자체적으로 View 를 찾지는 않으며 viewResolvers 에 설정된 ViewResolver 를 사용하여 View 를 찾음.

  • 예시

• 설명
  • mediatype 은 URL 의 확장자와 contentType 을 연결해주는 일종의 맵
  • 요청 경로에 포함된 확장자(html/xml...)를 ContentNegotiationManager Bean 구성 시 지정한 mediaTypes Map 을 이용해 기본 미더이 타입과 비교함.
    • 만약 요청 경로에 확장자는 있지만, 기본미디어 타입과 매치되는 확장자가 없으면,
      • JAF(JavaBeans Activation Framework)의 FileTypeMap을 이용해 이 확장자의 미디어 타입을 결정함.
        • JAF 관련 참고 페이지
          • https://www.oracle.com/technetwork/articles/java/index-135046.html
    • 만약 요청 경로에 확장자가 없으면, HTTP Accept 헤더를 활용함.
      • 즉, Accept 헤더에 지정된 값을 보면, 요청 URL에 확장자가 없어도 클라이언트가 기대하는 미디어 타입을 추론하는데 도움이 됨.
        • HTTP Accept 헤더의 값 예시
          • ex) Accept: text/html

결론

• 스프링MVC에서 View 는 웹 애플리케이션 컨텍스트에 하나 이상 선언된 뷰 리졸버 Bean을 해석함.
• 스프링MVC는 매우 유연한 뷰 리솔류션을 제공함.
  • 주요 다중 뷰 분석 전략
    • InternalResourceViewResolver
      • 템플릿의 이름과 위치에 뷰를 직접 매핑하는 뷰 리솔루션
    • XmlViewResolver
      • 외부 XML 구성을 기반으로 한 뷰 리솔루션
    • ResourceBundleViewResolver
      • XML 구성파일말고 리소스 번들에 뷰 Bean을 선언하는 뷰 리솔루션
    • ContentNegotiatingViewResolver
      • Accept 요청 헤더를 기반으로 다른 뷰 리졸버로 위임하는 뷰 리솔루션
• 오늘도 스프링MVC의 핵심개념 중 뷰(View) 리솔루션에 대한 지식 마술(?) 한가지 획득완료! 감사합니다.^^