Spring MVC определяет интерфейсы ViewResolver и View, которые позволяют визуализировать модели в браузере, не привязывая вас к конкретной технологии представления. ViewResolver обеспечивает сопоставление между именами представлений и реальными представлениями. View занимается подготовкой данных перед передачей в конкретную технологию представления.

В следующей таблице представлена более подробная информация об иерархии ViewResolver:

Таблица 3. Реализации ViewResolver
ViewResolver Описание

AbstractCachingViewResolver

Подклассы AbstractCachingViewResolver кэшируют экземпляры представлений, которые они распознают. Кэширование повышает производительность определенных технологий представления. Можно отключить кэш, установив свойство cache в false. Кроме того, если вам необходимо обновить определенное представление во время выполнения программы (например, при изменении шаблона FreeMarker), можно использовать метод removeFromCache(String viewName, Locale loc).

UrlBasedViewResolver

Простая реализация интерфейса ViewResolver, которая обеспечивает прямое разрешение логических имен представлений в URL-адреса без явного определения отображения. Это уместно, если ваши логические имена совпадают с именами ваших ресурсов представления в простой форме, без необходимости произвольного сопоставления.

InternalResourceViewResolver

Удобный подкласс UrlBasedViewResolver, который поддерживает InternalResourceView (по сути, сервлеты и JSP) и подклассы, такие как JstlView и TilesView. Можно задать класс представления для всех представлений, создаваемых этим распознавателем, используя setViewClass(..). Подробности см. в javadoc по UrlBasedViewResolver.

FreeMarkerViewResolver

Удобный подкласс UrlBasedViewResolver, поддерживающий FreeMarkerView и их пользовательские подклассы.

ContentNegotiatingViewResolver

Реализация интерфейса ViewResolver, который распознает представление на основе имени файла запроса или заголовка Accept.

BeanNameViewResolver

Реализация интерфейса ViewResolver, который интерпретирует имя представления как имя бина в текущем контексте приложения. Это очень гибкий вариант, который позволяет смешивать и сопоставлять различные типы представлений на основе различных имен представлений. Каждая такая реализация View может быть определена как бин, например, в XML-классах или в конфигурационных классах.
Java-университет

Обработка

Вы можете создавать цепочки распознавателей представлений, объявляя более одного бина распознавателя и, при необходимости, задавая свойство order для определения порядка. Помните, что чем выше свойство порядка, тем позже в цепочке располагается распознаватель представления.

Контракт ViewResolver определяет, что он может возвращать null, чтобы определить, что представление не может быть найдено. Однако в случае с JSP и InternalResourceViewResolver единственный способ выяснить, существует ли JSP, – это выполнить диспетчеризацию через RequestDispatcher. Поэтому всегда нужно располагать InternalResourceViewResolver в конфигурации последним в общем порядке распознавателей представлений.

Сконфигурировать распознавание представлений так же просто, как добавить бины ViewResolver в конфигурацию Spring. MVC Config предоставляет специальный конфигурационный API для распознавателей представлений и для добавления контроллеров представлений без алгоритма, которые полезны для визуализации HTML-шаблона без алгоритма управления.

Переадресация

Специальный префикс redirect: в имени представления позволяет выполнить переадресацию. UrlBasedViewResolver (и его подклассы) распознает это как команду осуществить необходимую переадресацию. Остальная часть имени представления – это URL-адрес переадресации.

Конечный результат такой же, как если бы контроллер возвращал RedirectView, но теперь сам контроллер может работать с именами логических представлений. Имя логического представления (например, redirect:/myapp/some/resource) осуществляет переадресацию относительно текущего контекста сервлета, в то время как имя, такое как redirect:https://myhost.com/some/arbitrary/path, осуществляет переадресацию на абсолютный URL-адрес.

Обратите внимание, что если метод контроллера аннотирован @ResponseStatus, значение аннотации имеет приоритет над статусом ответа, установленным RedirectView.

Перенаправление

Вы также можете использовать специальный префикс forward: для имен представлений, которые в конечном итоге распознаются UrlBasedViewResolver и подклассами. Это создает InternalResourceView, который выполняет RequestDispatcher.forward(). Поэтому этот префикс бесполезен при использовании InternalResourceViewResolver и InternalResourceView (для JSP), но он может оказаться полезным, если используется другая технология представления, но все же необходимо в принидительном порядке перенаправить ресурс на обработку контейнером сервлетов/JSP. Обратите внимание, что вместо этого также можно связать в цепочку несколько распознавателей представлений.

Согласование содержимого

ContentNegotiatingViewResolver не распознает представления самостоятельно, а делегирует эту работу другим распознавателям представлений и производит выборку представления, которое похоже на запрошенное клиентом. Представление может быть определено из заголовка Accept или из параметра запроса (например, "/path?format=pdf").

ContentNegotiatingViewResolver выбирает подходящее View для обработки запроса путём сравнения типов данных запроса с типом данных (также известным как Content-Type), поддерживаемым View, связанным с каждым из его ViewResolvers. Первое View в списке, которое имеет совместимый Content-Type, возвращает представление клиенту. Если цепочке ViewResolver не удается предоставить совместимое представление, используется список представлений, заданный в свойстве DefaultViews. Этот последний вариант подходит для одиночных Views, которые могут визуализировать соответствующее представление текущего ресурса независимо от имени логического представления. Заголовок Accept может содержать подстановочные знаки (например, text/*), в этом случае View, чье Content-Type равен text/xml, является совместимым.