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-класах або конфігураційних класах.

Обробка

Ви можете створювати ланцюжки розпізнавачів уявлень, оголошуючи більше одного бина розпізнавача і, за необхідності, задаючи властивість 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, є сумісним.