반응형 스택에서 이에 상응하는 내용 보기

Spring MVC는 특정 뷰 기술에 얽매이지 않고 브라우저에서 모델을 렌더링할 수 있게 해주는 ViewResolver 및 View 인터페이스를 정의합니다. ViewResolver는 뷰 이름과 실제 뷰 간의 매핑을 제공합니다. View는 특정 뷰 기술로 넘겨지기 전에 데이터를 준비하는 작업을 다룹니다.

다음 표에서는 ViewResolver 계층 구조에 대한 자세한 내용을 제공합니다.

표 1. ViewResolver 구현체

ViewResolver	설명
AbstractCachingViewResolver	AbstractCachingViewResolver의 하위 클래스는 해결한 뷰 인스턴스를 캐시합니다. 캐시는 특정 뷰 기술의 성능을 향상시킵니다. cache 속성을 false로 설정하여 캐시를 끌 수 있습니다. 또한 특정 뷰를 런타임에 새로 고칠 필요가 있을 때(예: FreeMarker 템플릿이 수정된 경우) removeFromCache(String viewName, Locale loc) 메서드를 사용할 수 있습니다.
UrlBasedViewResolver	ViewResolver 인터페이스의 간단한 구현으로, 명시적인 매핑 정의 없이 논리적 뷰 이름을 URL로 직접 resolve합니다. 논리적 이름이 임의의 매핑 없이 뷰 리소스의 이름과 일치하는 경우에 적합합니다.
InternalResourceViewResolver	UrlBasedViewResolver의 편리한 하위 클래스로, InternalResourceView(실제로 서블릿 및 JSP) 및 JstlView와 같은 하위 클래스를 지원합니다. 이 리졸버에 의해 생성된 모든 뷰에 대한 뷰 클래스를 setViewClass(..)를 사용하여 지정할 수 있습니다. 자세한 내용은 UrlBasedViewResolver javadoc을 참조하십시오.
FreeMarkerViewResolver	UrlBasedViewResolver의 편리한 하위 클래스로, FreeMarkerView와 해당 하위 클래스를 지원합니다.
ContentNegotiatingViewResolver	요청 파일 이름 또는 Accept 헤더를 기반으로 뷰를 resolve하는 ViewResolver 인터페이스의 구현체입니다. 콘텐츠 협상을 참조하십시오.
BeanNameViewResolver	뷰 이름을 현재 애플리케이션 컨텍스트의 빈 이름으로 해석하는 ViewResolver 인터페이스의 구현체입니다. 이는 매우 유연한 변형으로, 고유한 뷰 이름을 기반으로 다른 유형의 뷰를 혼합하고 매치할 수 있습니다. 각 View는 XML 또는 구성 클래스에서 빈으로 정의될 수 있습니다.

Handling

반응형 스택에서 이에 상응하는 내용 보기

하나 이상의 리졸버 빈을 선언하고, 필요한 경우 순서를 지정하는 order 속성을 설정하여 뷰 리졸버를 연결할 수 있습니다. order 속성이 높을수록 뷰 resolver가 체인에 더 늦게 배치된다는 점을 기억하세요.

ViewResolver의 계약은 뷰를 찾을 수 없음을 나타내기 위해 null을 반환할 수 있음을 지정합니다. 그러나 JSP 및 InternalResourceViewResolver의 경우 JSP가 존재하는지 알아내는 유일한 방법은 RequestDispatcher를 통해 디스패치를 수행하는 것입니다. 따라서 항상 InternalResourceViewResolver가 뷰 resolver의 전체 순서에서 마지막이 되도록 구성해야 합니다.

뷰 해상도 구성은 Spring 구성에 ViewResolver 빈을 추가하는 것만큼 간단합니다. MVC 구성은 뷰 resolver 및 컨트롤러 로직 없이 HTML 템플릿 렌더링에 유용한 로직 없는 뷰 컨트롤러를 추가하기 위한 전용 구성 API를 제공합니다.

Redirecting

반응형 스택에서 이에 상응하는 내용 보기

view 이름의 특수 redirect: 접두어를 사용하면 리디렉션을 수행할 수 있습니다. UrlBasedViewResolver(및 해당 하위 클래스)는 이를 리디렉션이 필요하다는 명령으로 인식합니다. view 이름의 나머지 부분은 리디렉션 URL입니다.

최종 효과는 컨트롤러가 RedirectView를 반환한 것과 동일하지만 이제 컨트롤러 자체가 논리적 뷰 이름으로 작동할 수 있습니다. 논리적 view 이름(예: redirect:/myapp/some/resource)은 현재 서블릿 컨텍스트를 기준으로 리디렉션되는 반면, redirect:https://myhost.com/some/arbitrary/path와 같은 이름은 절대 URL로 리디렉션됩니다.

Forwarding

UrlBasedViewResolver 및 하위 클래스에 의해 최종적으로 resolve되는 뷰 이름에 특별한 forward: 접두사를 사용할 수도 있습니다. 이는 RequestDispatcher.forward()를 수행하는 InternalResourceView를 생성합니다. 따라서 이 접두사는 InternalResourceViewResolver 및 InternalResourceView(JSP용)에는 유용하지 않지만, 다른 view technology을 사용하지만 여전히 Servlet/JSP 엔진에서 처리할 리소스를 강제로 전달하려는 경우에는 도움이 될 수 있습니다. 대신 여러 개의 뷰 리졸버를 연결할 수도 있습니다.

Content Negotiation

반응형 스택에서 이에 상응하는 내용 보기

ContentNegotiatingViewResolver는 뷰 자체를 resolve하지 않고 오히려 다른 뷰 resolver에게 위임하고 클라이언트가 요청한 표현(representation)과 유사한 뷰를 선택합니다. 표현은 Accept 헤더 또는 쿼리 매개변수(예: "/path?format=pdf")에서 결정될 수 있습니다.

ContentNegotiatingViewResolver는 요청 미디어 type을 각 ViewResolver와 연관된 View가 지원하는 미디어 type(Content-Type이라고도 함)과 비교하여 요청을 처리할 적절한 View를 선택합니다. 호환되는 Content-Type이 있는 목록의 첫 번째 View는 표현을 클라이언트에 반환합니다. ViewResolver 체인에서 호환 가능한 뷰를 제공할 수 없는 경우 DefaultViews 속성을 통해 지정된 view 목록이 참조됩니다. 후자의 옵션은 논리적 view 이름에 관계없이 현재 리소스의 적절한 표현을 렌더링할 수 있는 싱글톤 Views에 적합합니다. Accept 헤더에는 와일드카드(예: text/*)가 포함될 수 있으며, 이 경우 Content-Type이 text/xml인 View가 호환 가능합니다.

구성 세부 사항은 MVC 구성 아래의 View Resolvers를 참조하세요.