Это очень субъективный вопрос.Я лично не согласен с этой статьей и нахожу, что она дает действительно плохой совет для начинающих.
Управляемый компонент модели: Этот тип управляемого компонента участвует в "Модельной" проблемешаблон проектирования MVC.Когда вы видите слово «модель» - подумайте ДАННЫЕ.Бин модели JSF должен быть POJO, который следует шаблону проектирования JavaBean с инкапсулирующими свойствами геттеров / сеттеров.
Я бы совершенно не создавал и не называл его управляемым бином.Просто сделайте это свойство @ManagedBean
.Например, DTO или JPA @Entity
.
Backing Managed-Bean: этот тип управляемого компонента участвует в представлении "Просмотр" шаблона проектирования MVC.Назначение компонента поддержки - поддерживать логику пользовательского интерфейса и имеет отношение 1 :: 1 с представлением JSF или формой JSF в составе Facelet.Хотя обычно он имеет свойства стиля JavaBean со связанными получателями / установщиками, это свойства представления, а не модели данных базового приложения.Базовые компоненты JSF могут также иметь методы JSF actionListener и valueChangeListener.
Таким образом вы продолжаете дублировать и отображать свойства объекта в управляемом компоненте.Это не имеет смысла для меня.Как уже было сказано, просто сделайте сущность свойством управляемого компонента и позвольте входным полям ссылаться на него прямо как #{authenticator.user.name}
вместо #{authenticator.username}
.
Controller Managed-Bean: Этот тип управляемого компонента участвует в «контроллере» модели проектирования MVC.Цель bean-компонента контроллера - выполнить некую бизнес-логику и вернуть результат навигации в обработчик навигации JSF.Контроллер JSF обычно имеет методы действия JSF (а не методы actionListener).
Это в значительной степени описывает класс @RequestScoped
/ @ViewScoped
@ManagedBean
.Разрешены ли методы прослушивателя событий или нет, зависит от того, являются ли они специфичными для представления, связанного с компонентом и / или для их работы, в зависимости от состояния компонента.Если они есть, то они принадлежат бобу.Если нет, то они должны быть автономной реализацией любого FacesListener
интерфейса , но определенно не управляемого компонента.
Support Managed-Bean:Этот тип bean-компонента «поддерживает» одно или несколько представлений в «представлении» модели проектирования MVC.Типичным вариантом использования является предоставление ArrayList для JSF h: selectOneMenu раскрывающиеся списки, которые появляются в более чем одном представлении JSF.Если данные в раскрывающихся списках относятся к конкретному пользователю, то компонент будет находиться в области действия сеанса.
Fine.Для данных всего приложения, таких как выпадающие списки, просто используйте бин @ApplicationScoped
, а для данных всего сеанса, таких как зарегистрированный пользователь, и его предпочтения - @SessionScoped
.
Управляемый компонент Utility. Этот тип компонента предоставляет некоторый тип «служебной» функции для одного или нескольких представлений JSF.Хорошим примером этого может быть bean-компонент FileUpload, который может быть повторно использован в нескольких веб-приложениях.
Это не имеет для меня никакого смысла.Задние бобы обычно привязаны к одному виду.Это звучит слишком похоже на реализацию ActionListener
, которая должна использоваться <f:actionListener>
в компонентах команд по вашему выбору.Определенно не управляемый компонент.
Примеры запуска правильного подхода см. Также: