Інші вебфреймворки

Однією з основних пропонованих переваг Spring Framework є можливість вибору. Загалом, Spring не змушує використовувати чи купувати будь-яку конкретну архітектуру, технологію чи методологію (хоча він, звісно, має деякі рекомендації щодо тих чи інших). Ця свобода вибору архітектури, технології або методології, що найбільше підходить для розробника або його команди розробників, мабуть, найбільш явно проявляється у вебсфері, де Spring пропонує власні вебфреймворки (Spring MVC і Spring WebFlux), але в той же час підтримує інтеграцію з низкою популярних веб-сторонніх фреймворків.

Загальна конфігурація

Перш ніж зануритися в особливості інтеграції кожного вебфреймворку, що підтримується, давай спочатку розглянемо загальну конфігурацію Spring, яка не є специфічною для будь-якого одного вебфреймворку. (Цей розділ однаково застосовується до власних варіантів вебфреймворку Spring).

Одна з концепцій (через відсутність кращого слова), що підтримуються моделлю полегшених додатків Spring, — це багаторівнева архітектура. Пам'ятай, що в "класичній" багаторівневій архітектурі вебрівень є лише одним із багатьох. Він служить однією з точок входу в додаток на стороні сервера і делегує повноваження об'єктам-сервісам (фасадам), які визначені на сервісному рівні, по роботі зі специфічними бізнесовими сценаріями використання (і не залежать від технології подання). У Spring ці об'єкти-сервіси, будь-які інші бізнес-об'єкти, об'єкти доступу до даних тощо існують в окремому "бізнес-контексті", який не містить об'єктів вебрівня або рівня подання (об'єкти подання, такі як контролери Spring MVC, зазвичай конфігуруються в окремому "контексті рівня подання"). У цьому розділі докладно описано, як можна конфігурувати контейнер Spring (WebApplicationContext), що містить усі "бізнес-біни" твоєї програми.

Переходячи до конкретики, все, що потрібно зробити — це оголосити ContextLoaderListener у стандартному файлі Java EE-сервлета web.xml твоєї вебпрограми та додати секцію contextConfigLocation (у тому ж файлі), яка визначає, який набір конфігураційних XML-файлів Spring необхідно завантажити.

Розглянемо наступну конфігурацію <listener/>:

<listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>

Далі розглянемо наступну конфігурацію <context-param/>:

<context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/applicationContext*.xml</param-value>
</context-param>

Якщо ти не вкажеш параметр контексту contextConfigLocation, ContextLoaderListener буде шукати файл /WEB-INF/applicationContext.xml для завантаження. Після завантаження файлів контексту Spring створює об'єкт WebApplicationContext на основі визначень бінів і зберігає його до ServletContext вебпрограми.

Всі вебфреймворки Java побудовані на основі Servlet API, тому ти можеш використовувати наступний фрагмент коду для отримання доступу до цього "бізнес-контексту" ApplicationContext, створеного ContextLoaderListener.

У цьому прикладі показано, як отримати WebApplicationContext:

WebApplicationContext ctx = WebApplicationContextUtils.getWebApplicationContext(servletContext);

Клас WebApplicationContextUtils призначений для зручності, тому тобі не потрібно запам'ятовувати ім'я атрибуту ServletContext. Його метод getWebApplicationContext() повертає null, якщо об'єкт під ключем WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE не існує. Щоб уникнути отримання NullPointerExceptions у твоїй програмі, краще використовувати метод getRequiredWebApplicationContext(). Цей метод генерує виняток, якщо немає ApplicationContext.

Отримавши посилання на WebApplicationContext, можна отримувати біни за їхнім ім'ям або типом. Більшість розробників отримують біни на ім'я, а потім наводять їх до одного з реалізованих інтерфейсів.

На щастя, більшість фреймворків, описаних у цьому розділі, мають простіші способи пошуку бінів. Вони не лише спрощують отримання бінів із контейнера Spring, а й дозволяють використовувати впровадження залежностей у їхніх контролерах. У кожному розділі вебфреймворку докладніше описані конкретні стратегії інтеграції.

JSF

JavaServer Faces (JSF) — це стандартний компонентний, подієво-орієнтований фреймворк користувацького вебінтерфейсу, розроблений у межах процесу JCP. Він є офіційною частиною узагальненої специфікації Java EE, але також може використовуватися окремо, наприклад шляхом вбудовування Mojarra або MyFaces в Tomcat.

Зверни увагу, що останні версії JSF стали тісно пов'язані з інфраструктурою CDI в серверах додатків, і деякі нові функції JSF працюють тільки в такому оточенні. Засоби підтримки JSF у Spring більше активно не розвиваються і переважно застосовуються з метою міграції під час модернізации старих додатків на базі JSF.

Ключовим елементом інтеграції Spring з JSF є механізм ELResolver специфікації JSF.

Розпізнавальник бінів Spring

SpringBeanFacesELResolver – це реалізаціяELResolver, сумісна з JSF, що інтегрується зі стандартною уніфікованою мовою виразів (Unified EL), що використовується в JSF та JSP. Вона делегує повноваження спочатку WebApplicationContext "бізнес-контексту" Spring, а потім розпізнавачу за замовчуванням у базовій реалізації JSF.

З точки зору конфігурації, можна визначити SpringBeanFacesELResolver у файлі faces-context.xml специфікації JSF, як показано в наступному прикладі:

<faces-config>
    <application>
        <el-resolver>org.springframework.web.jsf.el.SpringBeanFacesELResolver</el-resolver>
        ...
    </application>
</faces-config>

Використання FacesContextUtils

Кастомний ELResolver чудово працює при відображенні властивостей на біни в faces-config.xml, але іноді може знадобитися явне захоплення біна. Клас FacesContextUtils полегшує це завдання. Він схожий на WebApplicationContextUtils, за винятком того, що приймає параметр FacesContext, а не ServletContext.

У цьому прикладі показано, як використовувати FacesContextUtils:

ApplicationContext ctx = FacesContextUtils.getWebApplicationContext(FacesContext.getCurrentInstance());

Apache Struts 2.x

Фреймворк Struts, придуманий Крейгом МакКланаханом, є проєктом з відкритим вихідним кодом на базі Apache Software Foundation. Тоді він значно спростив парадигму програмування JSP/Servlet і підкорив багатьох розробників, які використовували пропрієтарні фреймворки. Він спрощував модель програмування, мав відкритий вихідний код (а отже, був безкоштовним), і мав широку спільноту, що дозволяло проєкту розвиватися та бути популярним серед веброзробників на Java.

Як із наступником оригінального Struts 1.x, ознайомся зі Struts 2.x і наданим у Struts плагіном для Spring, призначеним для вбудованої інтеграції зі Spring.

Apache Tapestry 5.x

Tapestry — це "компонентно-орієнтований фреймворк для створення динамічних, надійних, масштабованих вебдодатків на Java" .

Хоча Spring і має власний потужний вебрівень, створення корпоративного Java-додатка з використанням комбінації з Tapestry для користувацького вебінтерфейсу та контейнера Spring для нижчих рівнів дає низку унікальних переваг.

Для отримання додаткової інформації див. спеціальний інтеграційний модуль Tapestry для Spring .

Додаткові джерела

Наступні посилання ведуть на додаткові джерела, присвячені різним вебфреймворкам, описаним у цьому розділі.

• Домашня сторінка JSF

• Домашня сторінка Struts

• Домашня сторінка Tapestry