Различение между различными видами фасоли JSF

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

  • Управляемый компонент модели: этот тип управляемого компонента участвует в "модели" модели проектирования MVC. Когда вы видите слово "модель" - подумайте ДАННЫЕ. Компонент JSF-модели должен быть POJO, который следует шаблону проектирования JavaBean с инкапсулирующими свойствами getter /setters.

  • Backing Managed-Bean: этот тип управляемого компонента участвует в "представлении" модели проектирования MVC. Назначение backing-bean-компонента - поддерживать логику пользовательского интерфейса и имеет отношение 1::1 с представлением JSF или формой JSF в составе Facelet. Хотя обычно он имеет свойства стиля JavaBean со связанными получателями / установщиками, это свойства представления, а не модели данных базового приложения. У компонентов поддержки JSF также могут быть методы JSF actionListener и valueChangeListener.

  • Управляемый компонент Controller: этот тип управляемого компонента участвует в "контроллере" модели проектирования MVC. Цель bean-компонента контроллера - выполнить некоторую бизнес-логику и вернуть результат навигации в обработчик навигации JSF. Контроллер JSF обычно имеет методы действия JSF (а не методы actionListener).

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

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

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

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

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

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

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

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

Источник

1 ответ

Решение

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

Управляемый компонент модели: этот тип управляемого компонента участвует в "модели" модели проектирования MVC. Когда вы видите слово "модель" - подумайте ДАННЫЕ. Компонент JSF-модели должен быть POJO, который следует шаблону проектирования JavaBean с инкапсулирующими свойствами getter /setters.

Я бы не стал делать или называть это управляемым бобом. Просто сделайте это свойством @ManagedBean, Например, DTO или JPA @Entity,

Backing Managed-Bean: этот тип управляемого компонента участвует в "представлении" модели проектирования MVC. Назначение backing-bean-компонента - поддерживать логику пользовательского интерфейса и имеет отношение 1::1 с представлением JSF или формой JSF в составе Facelet. Хотя обычно он имеет свойства стиля JavaBean со связанными получателями / установщиками, это свойства представления, а не модели данных базового приложения. У компонентов поддержки JSF также могут быть методы JSF actionListener и valueChangeListener.

Таким образом, вы продолжаете дублировать и отображать свойства объекта в управляемом компоненте. Это не имеет смысла для меня. Как уже было сказано, просто сделайте сущность свойством управляемого компонента и позвольте входным полям ссылаться на него напрямую, как #{authenticator.user.name} вместо #{authenticator.username},

Управляемый компонент Controller: этот тип управляемого компонента участвует в "контроллере" модели проектирования MVC. Цель bean-компонента контроллера - выполнить некоторую бизнес-логику и вернуть результат навигации в обработчик навигации JSF. Контроллер JSF обычно имеет методы действия JSF (а не методы actionListener).

Это описывает @RequestScoped / @ViewScoped@ManagedBean класс довольно Разрешены ли методы прослушивателя событий или нет, зависит от того, являются ли они специфичными для представления, связанного с компонентом и / или для их работы, в зависимости от состояния компонента. Если они есть, то они принадлежат бобу. Если нет, то они должны быть автономной реализацией любого FacesListener интерфейс, но определенно не управляемый компонент.

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

Хорошо. Для данных всего приложения, таких как выпадающие списки, просто используйте @ApplicationScoped бина и для данных всей сессии, таких как вошедший в систему пользователь и его предпочтения просто использовать @SessionScoped один.

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

Это не имеет никакого смысла для меня. Задние бобы обычно привязаны к одному виду. Это звучит слишком похоже на ActionListener реализация, которая должна использоваться <f:actionListener> в компонентах команды на ваш выбор. Определенно не управляемый боб.

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

Источник
Другие вопросы по тегам