1. Технология JavaServer Faces. Особенности, отличия от сервлетов и JSP, преимущества и недостатки. Структура JSF-приложения.

JavaServer Faces (JSF) — это фреймворк для веб-приложений, облегчающий разработку пользовательских интерфейсов Java EE приложений. Основывается на использовании компонентов. Состояние компонентов пользовательского интерфейса сохраняется, когда пользователь запрашивает новую страницу и затем восстанавливается, если запрос повторяется.

Отличия от JSP:

Критерий	JSF	JSP
Тип	Фреймворк для веб-приложений	Технология для создания динамического веб-контента
Цель	Упрощение разработки пользовательского интерфейса	Генерация HTML и встраивание Java кода
Функционал	jsf содержит множество основных функций, включая, managed beans, систему компонентов на основе шаблонов и библиотеки тегов на основе xml.	JSF должен быть скомпилирован в byte code чтобы работать
Состояние компонентов	Управляется автоматически	Разработчику нужно самому управлять состоянием
Интеграция с библиотеками	Легко интегрируется с библиотеками компонентов (PrimeFaces и тд)	Минимальная или нет интеграции
Язык шаблонов	Facelets	Нет встроенных шаблонов, но можно использовать JSTL
Тестирование	Обычно сложнее из-за высокого уровня абстракции	Проще тестировать
Скорость разработки	Обычно быстрее для сложных приложений	Может быть медленнее для сложных приложений

Преимущества JSF

Четкое разделение бизнес-логики и интерфейса
Управление на уровне компонент
Простая работа с событиями на стороне сервера
Расширяемость (доп. наборы компонентов)
Доступность нескольких реализаций от различных компаний-разработчиков
Широкая поддержка со стороны интегрированных средств разработки (IDE)

Недостатки JSF:

Высокоуровневый фреймворк — сложно реализовывать не предусмотренную авторами функциональность.
Сложности с обработкой GET-запросов (устранены в JSF 2.0).
Сложность разработки собственных компонентов.

Структура JSF-приложения

JSP или XHTML страницы с компонентами GUI
Библиотека тегов
Управляемые бины
Доп. объекты(компоненты, конвертеры, валидаторы)
Доп. теги
Конфигурация – faces-config.xml
Дескриптор развертывания – web.xml

2. Использование JSP-страниц и Facelets-шаблонов в JSF-приложениях.

В JSF (JavaServer Faces) можно использовать как JSP-страницы, так и Facelets-шаблоны. Однако, начиная с JSF 2.0, рекомендуется использовать Facelets вместо JSP. Это обеспечивает отличные возможности шаблонов, такие как составные компоненты, в то время как JSP в основном предлагает jsp:include для шаблонов, так что вы вынуждены создавать пользовательские компоненты с необработанным кодом Java, когда вы хотите заменить повторяющуюся группу компонентов одним компонентом.

Сравнение:

Шаблонизация: Facelets предлагает более мощные возможности для шаблонизации и вложенности шаблонов.
Состояние компонентов: Facelets лучше сохраняет состояние компонентов между запросами, что делает его предпочтительным для современных JSF-приложений.
Совместимость: JSP можно использовать в старых JSF 1.x приложениях, но для новых проектов рекомендуется использовать Facelets.
Производительность: Facelets обычно предоставляет лучшую производительность, поскольку он спроектирован специально для JSF.

3. JSF-компоненты - особенности реализации, иерархия классов. Дополнительные библиотеки компонентов. Модель обработки событий в JSF-приложениях.

Особенности реализации:

Интерфейс строится из компонентов.
Компоненты расположены на Facelets-шаблонах или страницах JSP.
Компоненты реализуют интерфейс javax.faces.component.UIComponent.
Можно создавать собственные компоненты.
Компоненты на странице объединены в древовидную структуру — представление.
Корневым элементов представления является экземпляр класса javax.faces.component.UIViewRoot.

Иерархия классов (фрагмент)

-- javax.faces.component.UIComponent
---- javax.faces.component.UIComponentBase
------ javax.faces.component.UIOutput
-------- javax.faces.component.UIInput
---------- javax.faces.component.UISelectOne
---------- javax.faces.component.UISelectMany

Дополнительные библиотеки компонентов

PrimeFaces: богатый набор компонентов, таких как таблицы, графики, диалоговые окна и многое другое. Он имеет стильные и современные компоненты с возможностью легкой настройки и расширения.
RichFaces: набор AJAX-компонентов для JSF. Он включает в себя такие компоненты, как автодополнение, графики, календари и деревья. RichFaces позволяет создавать динамические и интерактивные веб-приложения.
IceFaces: open-source, компоненты и функциональность для разработки интернет-приложений с использованием JSF и AJAX-технологий. Он также поддерживает интеграцию с различными серверами приложений.
... и тд, все примерно одна фигня, зачастую взаимозаменяемы

Модель обработки событий

Жизненный цикл обработки запроса в приложениях JSF состоит из следующих фаз:

Восстановление представления (JSF Runtime синхронизирует состояние компонентов представления с клиентом.)
Использование параметров запроса; конвертация значений
Проверка данных; вычисление значений
Обновление значений модели (связывание их с полями бинов)
Запуск приложения; обработка событий, методов, правил навигации
Генерация ответа, завершения жизненного цикла JSF

Подробнее о фазах:

Фаза формирования представления

JSF Runtime формирует представление (начиная с UIViewRoot):
Создаются объекты компонентов.
Назначаются слушатели событий, конвертеры и валидаторы.
Все элементы представления помещаются в FacesContext.
Если это первый запрос пользователя к странице JSF, то формируется пустое представление.
Если это запрос к уже существующей странице, то JSF Runtime синхронизирует состояние компонентов представления с клиентом.

Фаза получения значений компонентов

Значения переменных из запроса пихаются в компонент
На стороне клиента все значения хранятся в строковом формате — нужна проверка их корректности:
Вызывается конвертер в соответствии с типом данных значения.
Если конвертация заканчивается успешно, значение сохраняется в локальной переменной компонента.
Если конвертация заканчивается неудачно, создаётся сообщение об ошибке, которое помещается в FacesContext.

Фаза валидации значений компонентов

Вызываются валидаторы, зарегистрированные для компонентов представления.
Если значение компонента не проходит валидацию, формируется сообщение об ошибке, которое сохраняется в FacesContext.

Фаза обновления значений компонентов

Если данные валидны, то значение компонента обновляется.
Новое значение присваивается полю объекта компонента.

Фаза вызова приложения

Управление передаётся слушателям событий.
Формируются новые значения компонентов.

Фаза формирования ответа сервера

JSF Runtime обновляет представление в соответствии с результатами обработки запроса.
Если это первый запрос к странице, то компоненты помещаются в иерархию представления.
Формируется ответ сервера на запрос.
На стороне клиента происходит обновление страницы.

4. Конвертеры и валидаторы данных.

Конверторы

Используются для преобразования данных в заданный формат
Реализуют интерфейс javax.convert.Converter
Стандартные конверторы для основных типов данных (javax.faces.Boolean, javax.faces.DateTime, javax.faces.Double, javax.faces.Character, etc.)
JSF также позволяет создавать собственные конверторы.

Назначение конверторов:

Автоматическое (на основании типов данных)
С помощью атрибута converter (когда хотим явно указать к чему приводим)
С помощью вложенного тега (также, только через доп тег <f: converterID=.../>; можно задавать доп. атрибуты для конвертора)

Валидаторы

Осуществляются перед обновлением значения компонента в модели
Класс валидатора должен реализовывать интерфейс javax.faces.validator.Validator
Есть стандартные валидаторы + можно создавать свои

Способы валидации:

С помощью параметров компонента (required="true")
С помощью вложенного тега (<f:validateDoubleRange minimum="-5" maximum="5"/>)
С помощью логики на уровне managed bean

5. Представление страницы JSF на стороне сервера. Класс UIViewRoot.

За представление отвечают:

UI Component. Объект с состоянием, методами, событиями, который содержится на сервере и отвечает за взаимодействие с пользователем (визуальный компонент). Каждый UI компонент содержит метод метод render для прорисовки самого себя, согдасно правилам в классе Render
Renderer - Отвечает за отображение компонента и преобразование ввода пользователя
Validator, Convertor
Backing bean - собирает значения из компонент, реагирует на события, взаимодействует с бизнес-логикой.
Events, Listeners, Message
Navigation - =правила навигации между страницами, задаются в виде xml документа

UIViewRoot

Объект UIViewRoot дает представление JSF, он связан с активным FacesContext. JSF реализация создаёт представление при первом обращении (запросе), либо восстанавливает уже созданное. Когда клиент отправляет форму (postback), JSF конвертирует отправленные данные, проверяет их, сохраняет в managed bean, находит представление для навигации, восстанавливает значения компонента из managed bean, генерирует ответ по представлению. Все эти действия JSF описываются с помощью 6 упорядоченных процессов.

6. Управляемые бины - назначение, способы конфигурации. Контекст управляемых бинов.

Управляемые бины – классы, содержащие параметры и методы для обработки данных с компонентов. Должны иметь методы get / set. Используются для обработки UI и валидации данных. Жизненным циклом управляет JSF Runtime Env. Доступ из JSP-страниц осуществляется с помощью языка выражений (EL). Конфигурация задается либо в faces-config.xml, либо с помощью аннотаций (JSF 2.0).

У управляемых бинов есть контекст, который определяет продолжительность жизни. Он задается аннотацией (или в конфиг файле, если мы объявляем бины там).

Аннотации

@RequestScoped - используется по умолчанию. Создаётся новый экземпляр managed bean на каждый HTTP запрос (и при отправке, и при получении). Контекст - запрос

@SessionScoped - экземпляр создаётся один раз при обращении пользователя к приложению, и используется на протяжении жизни сессии. Managed bean обязательно должен быть Serializable. Контекст — сессия.

@ApplicationScoped - экземпляр создаётся один раз при обращении и используется на протяжении жизни всего приложения. Не должен иметь состояния, а если имеет, то должен синхронизировать доступ, так как доступен для всех пользователей. Контекст — приложение.

@ViewScoped - экземпляр создаётся один раз при обращении к странице, и используется ровно столько, сколько пользователь находится на странице (включая ajax запросы). Контекст — страница, представление.

@CustomScoped(value="#{someMap}") - экземпляр создаётся и сохраняется в Map. Программист сам управляет областью жизни.

@NoneScoped - экземпляр создаётся, но не привязывается ни к одной области жизни. Жизненным циклом управляют другие managed beans. Бин без контекста.

7. Конфигурация JSF-приложений. Файл faces-config.xml. Класс FacesServlet.

faces-config.xml — конфигурационный файл JavaServer Faces, который должен находиться в директории WEB-INF проекта. В этом файле могут находиться настройки managed bean, конвертеры, валидаторы, локализация, навигации и другие настройки, связанные с JSF.

Класс FacesServlet

Центральный компонент в архитектуре JSF, контроллер в шаблоне MVC
Обрабатывает запросы с браузера.
Формирует объекты-события и вызывает методы-слушатели.
Управляет жизненным циклом запроса (прохождение через все фазы)
Конфигурация задается в web.xml

8.Навигация в JSF-приложениях.

Правила навигации — это правила, предоставляемые JSF Framework, которые описывают, какое представление должно отображаться при нажатии кнопки или ссылки.

Механизм навигации JSF позволяет определить связь между логическим признаком результата и следующим представлением. Реализуется объектами NavigationHandler. Навигация осуществляется с помощью правил перехода.

Правила задаются в файле faces-config.xml, еще можно непосредственно через <h:outputlink>:

<h:outputLink value="pages/calculator.jsf">
<h:outputText value="Calculator Application (outputlink)"/>
</h:outputLink>

9. Доступ к БД из Java-приложений. Протокол JDBC, формирование запросов, работа с драйверами СУБД.

Протокол JDBC:

JDBC (Java Database Connectivity) — это API в Java, предназначенный для подключения и выполнения запросов к различным базам данных. Он позволяет Java-приложениям взаимодействовать с базами данных посредством драйверов СУБД. Он сочетает функции шлюзования между интерпретатором мобильных Java-кодов и интерфейсом ODBC (Open Data Base Connectivity).

ODBC - это открытый интерфейс, который может использоваться любым приложением для связи с любой системой баз данных, а JDBC - это интерфейс, который может использоваться приложениями Java для доступа к базам данных. JDBC больше подходит для объектно-ориентированных баз данных, однако можно получить доступ к любой ODBC-совместимой базе данных, используя мост JDBC-ODBC.

Архитектура JDBC состоит из двух уровней: JDBC API, который обеспечивает связь между приложением и менеджером JDBC и драйвер JDBC API, который поддерживает связь между JDBC менеджером и драйвером СУБД.

Запрос:

Запрос (query) – это средство выбора необходимой информации из базы данных. Применяются два типа запросов: по образцу (QBE) и структурированный язык запросов (SQL). Существует несколько типов запросов: на выборку, на обновление, на добавление, на удаление, перекрестный запрос, создание таблиц. Запросы на выборку используются для отбора нужной пользователю информации, содержащейся в таблицах, используются чаще всего. Они создаются только для связанных таблиц.

Драйвер СУБД:

JDBC-драйвер – реализация JDBC для определенной базы данных. Задача драйвера упаковывать запрос, параметры и результаты в пакеты, передаваемые по сети. Формат упаковки языком никак не оговаривается, и каждая СУБД реализует его по своему.

10. Концепция ORM. Библиотеки ORM в приложениях на Java. Основные API. Интеграция ORM-провайдеров с драйверами JDBC.

ORM — это концепция, которая позволяет взаимодействовать с реляционными базами данных в терминах объектно-ориентированных объектов. Она скрывает подробности SQL-запросов, позволяя работать с таблицами реляционной базы данных как с обычными Java-классами, занимается связыванием объектов в программе и записей в таблицах базы данных.

Библиотеки ORM в приложениях на Java

Hibernate: Один из самых популярных ORM-фреймворков в Java. Предоставляет богатые возможности для маппинга, кэширования, ленивой загрузки и др.
JPA (Java Persistence API): Стандартный Java EE API для ORM. Hibernate, EclipseLink и другие могут служить его провайдерами.
EclipseLink: Реализация JPA от Eclipse Foundation.
JDO (Java Data Objects): Альтернатива JPA с более сложными возможностями маппинга.
ActiveJDBC: Простой и быстрый ORM-фреймворк, следующий принципам "Convention over Configuration".

Основные API

Сущности (Entities): POJO-классы, которые представляют таблицы в базе данных.
EntityManager: Интерфейс для управления сущностями.
Query: Интерфейс для выполнения JPQL (JPA Query Language) запросов.
Annotations: Аннотации (например, @Entity, @Table, @Column) используются для конфигурации маппинга.
SessionFactory / EntityManagerFactory: Используется для создания Session или EntityManager.
Transaction: Интерфейс для управления транзакциями.

Интеграция ORM-провайдеров с драйверами JDBC

ORM-фреймворки, такие как Hibernate и JPA, внутренне используют JDBC для взаимодействия с базой данных. Здесь как это обычно работает:

Настройка соединения: ORM-фреймворк использует JDBC драйвер для установления соединения с базой данных.
Выполнение запросов: SQL-запросы генерируются автоматически на основе маппинга и отправляются на сервер базы данных через JDBC.
Обработка результата: Результаты, полученные через JDBC, преобразуются обратно в объекты.
Управление транзакциями: ORM фреймворки могут использовать JDBC для управления транзакциями, предоставляя более высокоуровневый API для этого.

11. Библиотеки ORM Hibernate и EclipseLink. Особенности, API, сходства и отличия.

Hibernate и EclipseLink: Обзор

Оба фреймворка являются реализациями Java Persistence API (JPA) и предоставляют возможности для Object-Relational Mapping (ORM) в Java-приложениях.

Особенности Hibernate

Lazy Loading: Поддерживает ленивую инициализацию по умолчанию (загрузка или инициализация объекта, данных или операций откладывается до момента, когда они действительно необходимы, улучшает производительность).
Caching: Встроенная поддержка первого и второго уровней кэширования.
HQL (Hibernate Query Language): Собственный язык запросов.
Rich Mapping: Обширные возможности для сложного маппинга сущностей.

Особенности EclipseLink

JPA Reference Implementation: Является стандартной реализацией JPA.
MOXy (JAXB): Поддержка преобразования объектов в XML и JSON.
Caching: Поддержка кэширования, но несколько менее гибкая, чем в Hibernate.
JPQL (Java Persistence Query Language): Стандартный язык запросов для JPA.

Сравнение API

EntityManager: Используется в обоих фреймворках для CRUD-операций и управления транзакциями.

// Hibernate и EclipseLink
EntityManager em = entityManagerFactory.createEntityManager();
em.getTransaction().begin();
em.persist(myEntity);
em.getTransaction().commit();

Annotations: Оба фреймворка используют стандартные JPA-аннотации (@Entity, @Table, @Column, и т.д.).
Query Language: Hibernate предоставляет HQL, в то время как EclipseLink полагается на стандартный JPQL. Однако оба фреймворка поддерживают JPQL.

Сходства

JPA Compliance: Оба фреймворка являются реализациями JPA.
ACID Transactions: Поддержка ACID транзакций.
Caching: Механизмы кэширования.
Annotations: Используют аннотации для маппинга сущностей.

Отличия

Query Language: Hibernate использует HQL, EclipseLink — JPQL (хотя оба поддерживают JPQL).
Performance: Hibernate обычно считается более быстрым для сложных операций маппинга, тогда как EclipseLink может быть проще в настройке и использовании.
Flexibility: Hibernate предлагает более гибкие возможности маппинга и кэширования.
Standards: EclipseLink является референсной реализацией JPA, и поэтому строже следует стандартам JPA.
Extra Features: Hibernate предоставляет дополнительные возможности, такие как Criteria API, для программного создания запросов, что может быть отсутствует в EclipseLink.

12. Технология JPA. Особенности, API, интеграция с ORM-провайдерами.

JPA – это технология, обеспечивающая объектно-реляционное отображение простых JAVA объектов и предоставляющая API для сохранения, получения и управления такими объектами. Сам JPA не умеет ни сохранять, ни управлять объектами, JPA только определяет правила игры: как что-то будет действовать. JPA также определяет интерфейсы, которые должны будут быть реализованы провайдерами. Плюс к этому JPA определяет правила о том, как должны описываться метаданные отображения и о том, как должны работать провайдеры. Дальше, каждый провайдер, реализуя JPA определяет получение, сохранение и управление объектами. У каждого провайдера реализация разная.

Особенности

Аннотации: Предоставляет аннотации (@Entity, @Table, @Id и др.) для маппинга объектов Java на таблицы реляционных баз данных.
EntityManager: Интерфейс для CRUD-операций и транзакций.
JPQL (Java Persistence Query Language): Язык для создания запросов к данным, независимый от базы данных.
Кэширование: Поддержка первого и второго уровней кэширования.
Ленивая инициализация: Оптимизация производительности за счет отложенной загрузки данных.
Встраиваемые объекты: Поддержка вложенных объектов и сложных типов.
Транзакции: Поддержка ACID-транзакций.

API

Основными классами и интерфейсами являются:

EntityManagerFactory: для создания EntityManager.
EntityManager: для управления сущностями.
EntityTransaction: для управления транзакциями.
Query и TypedQuery: для создания и выполнения запросов.

Интеграция с ORM-провайдерами

JPA — это лишь спецификация, и для ее использования необходима реализация. Существуют различные провайдеры, такие как Hibernate, EclipseLink и OpenJPA, которые предоставляют реализацию JPA.

Если простыми словами суммировать все вышесказанное:

Есть 3 разных уровня абстракции:

ORM - концепция. Она просто говорит, что можно брать таблицы из БД и работать с ними как с объектами.
JPA - спецификация. Она предоставляет набор интерфейсов и правил как это должно происходить.
Провайдер (типа Hibernate или EclipseLink) - реализация. Он уже непосредственно производит маппинг и преобразует таблицы в объекты по набору правил JPA.

Files

theory.md

Latest commit

History