Различение между различными видами фасоли JSF - PullRequest
45 голосов
/ 28 августа 2011

Я недавно прочитал эту статью от Нила Гриффина Определение различий между различными видами управляемых bean-компонентов JSF , и это заставило меня задуматься о различии между различными bean-компонентами в моем собственном приложении. Чтобы быстро суммировать суть:

  • Модель управляемого компонента: Этот тип управляемого компонента участвует в «Модельный» концерн шаблона проектирования MVC. Когда вы видите слово «Модель» - подумайте ДАННЫЕ. Модельный бин JSF должен быть POJO, который следует шаблон проектирования JavaBean с инкапсуляцией геттеров / сеттеров свойства.

  • Backing Managed-Bean: этот тип управляемого компонента участвует в «Вид» озабоченность шаблона проектирования MVC. Цель backing-bean-компонент предназначен для поддержки логики пользовательского интерфейса и имеет отношение 1 :: 1 к представление JSF или форма JSF в композиции Facelet. Хотя это обычно имеет свойства в стиле JavaBean со связанными getters / setters, это свойства View, а не базовая модель данных приложения. Бэк-бобы JSF также могут иметь JSF Методы actionListener и valueChangeListener.

  • Контролируемый компонент: Этот тип управляемого компонента участвует в «Контроллер» касается шаблона проектирования MVC. Цель Контроллер должен выполнять некоторую бизнес-логику и возвращать навигационный результат к навигационному обработчику JSF. JSF контроллер бобы обычно есть методы действия JSF (а не методы actionListener).

  • Поддержка управляемого компонента: Этот тип компонента "поддерживает" одно или несколько представлений в концерне «View» шаблона проектирования MVC. Типичный вариант использования предоставляет ArrayList в JSF h: раскрывающийся список selectOneMenu списки, которые появляются в более чем одном представлении JSF. Если данные в выпадающие списки являются специфическими для пользователя, тогда бин будет сохранен в объеме сеанса.

  • Служебный управляемый компонент: Этот тип компонента предоставляет некоторый тип Функция "Утилита" для одного или нескольких представлений JSF. Хороший пример этого может быть компонентом FileUpload, который может быть повторно использован в нескольких сетях приложения.

Это имело смысл для меня, и в течение последних нескольких часов я проводил рефакторинг своего кода и придумал следующее в отношении логина пользователя:

AuthenticationController - пример управляемого компонента. Он ограничен запросами и имеет два метода получения и установки для установки имени пользователя и пароля, а также два метода навигации, authenticate и logout, для перехода пользователя в личную зону при успешном входе в систему или обратно на главную страницу при выход из системы.

UserBean является примером компонента поддержки. Он имеет сессионную область и содержит экземпляр класса User (который будет нулевым, если вы не аутентифицированы) с использованием методов получения и установки, и ничего более.

У AuthenticationController этот пользователь является управляемым свойством (@ManagedProperty(value = "#{userController.user} private User user;). После успешной аутентификации AuthenticationController установит управляемое свойство для фактического пользовательского экземпляра с соответствующим именем пользователя, которое использовалось для входа в систему.

Любые новые bean-компоненты смогут также захватывать пользователя как управляемое свойство и извлекать необходимые данные, например, членство в группах, если класс User будет содержать список с именами групп.

Будет ли этот путь правильным для разделения проблем?

1 Ответ

88 голосов
/ 29 августа 2011

Это очень субъективный вопрос.Я лично не согласен с этой статьей и нахожу, что она дает действительно плохой совет для начинающих.


Управляемый компонент модели: Этот тип управляемого компонента участвует в "Модельной" проблемешаблон проектирования 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> в компонентах команд по вашему выбору.Определенно не управляемый компонент.

Примеры запуска правильного подхода см. Также:

...