Структура вспомогательного компонента JSF (лучшие практики)

Question

Я надеюсь, что в этом посте я смогу узнать мнение людей о передовых методах взаимодействия между страницами JSF и компонентами поддержки.

Одна вещь, на которой я никогда не могу остановиться - это структура моих бобов. Кроме того, я никогда не нашел хорошую статью на эту тему.

Каким свойствам принадлежат какие бобы? Когда целесообразно добавить больше свойств к данному бину, а не создавать новый бин и добавлять к нему свойства? Для простых приложений имеет ли смысл просто иметь один компонент поддержки для всей страницы, учитывая сложность, связанную с внедрением одного компонента в другой? Должен ли компонент поддержки содержать какую-либо действительную бизнес-логику или он должен строго содержать данные?

Не стесняйтесь отвечать на эти и любые другие вопросы, которые могут возникнуть.

<ч />

Что касается уменьшения связи между страницей JSF и компонентом поддержки, я никогда не позволяю странице JSF получать доступ к свойствам какого-либо компонента поддержки. Например, я никогда не разрешаю что-то вроде:

<h:outputText value="#{myBean.anObject.anObjectProperty}" />

Мне всегда нужно что-то вроде:

<h:outputText value="#{myBean.theObjectProperty}" />

со значением базового компонента:

public String getTheObjectProperty()
{
    return anObject.getAnObjectProperty();
}

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

В общем, этот подход мне кажется "правильным". Это позволяет избежать какой-либо связи между представлением и данными. Пожалуйста, поправьте меня, если я ошибаюсь.

Answer 1

Возможно, вы захотите проверить это: проводя различия между различными типами управляемых JSF-компонентов .

Вот описание различных типов бинов, как определено в вышеупомянутой статье Нилом Гриффином:

• Управляемый компонент модели : Обычно область сеанса. Этот тип управляемого компонента участвует в проблеме "Модель" шаблона проектирования MVC. Когда вы видите слово «модель» - подумайте ДАННЫЕ. Компонент JSF-модели должен быть POJO, который следует шаблону проектирования JavaBean с инкапсулирующими свойствами getter / setters. Наиболее распространенный вариант использования модельного компонента - это объект базы данных или просто представление набора строк из набора результатов запроса базы данных.
• Backing Managed-bean : Обычно область запроса. Этот тип управляемого Bean участвует в проблеме "View" шаблона проектирования MVC. Назначение компонента поддержки - поддерживать логику пользовательского интерфейса и имеет отношение 1 :: 1 с представлением JSF или формой JSF в составе Facelet. Хотя обычно он имеет свойства стиля JavaBean со связанными получателями / установщиками, это свойства представления, а не модели данных базового приложения. У компонентов поддержки JSF также могут быть методы JSF actionListener и valueChangeListener.
• Контролируемый управляемый компонент : Обычно запрашиваемая область. Этот тип управляемого компонента участвует в проблеме "Контроллер" шаблона проектирования MVC. Цель bean-компонента контроллера - выполнить некую бизнес-логику и вернуть результат навигации в обработчик навигации JSF. Контроллер JSF обычно имеет методы действия JSF (а не методы actionListener).
• Support Managed-bean : Обычно область сеанса или приложения. Этот тип bean-компонента "поддерживает" одно или несколько представлений в отношении "View" шаблона проектирования MVC. Типичным вариантом использования является предоставление ArrayList для JSF h: selectOneMenu раскрывающиеся списки, которые появляются в более чем одном представлении JSF. Если данные в раскрывающихся списках относятся к конкретному пользователю, то компонент будет оставаться в области действия сеанса. Однако если данные применяются ко всем пользователям (например, раскрывающимся спискам провинций), то компонент будет оставаться в области приложения, чтобы его можно было кэшировать для всех пользователей.
• Utility Managed-Bean : Обычно область применения. Этот тип компонента предоставляет некоторый тип «служебной» функции для одного или нескольких представлений JSF. Хорошим примером этого может служить bean-компонент FileUpload, который можно повторно использовать в нескольких веб-приложениях.

Answer 2

Отличный вопрос. Я много страдал с той же дилеммой, когда перешел в JSF. Это действительно зависит от вашего приложения. Я из мира Java EE, поэтому я бы рекомендовал иметь как можно меньше бизнес-логики в ваших бинах. Если логика связана исключительно с представлением вашей страницы, тогда хорошо иметь ее в компоненте поддержки.

Я считаю, что одной из (многих) сильных сторон JSF является тот факт, что вы можете выставлять доменные объекты непосредственно на управляемых bean-компонентах. Поэтому я настоятельно рекомендую подход <:outputText value="#{myBean.anObject.anObjectProperty}" />, в противном случае вы в конечном итоге сделаете слишком много работы для себя, вручную выставляя каждое свойство. Кроме того, было бы немного беспорядочно при вставке или обновлении данных, если вы инкапсулировали все свойства. Существуют ситуации, когда одного объекта домена может быть недостаточно. В этих случаях я готовлю ValueObject перед тем, как выставить его на боб.

РЕДАКТИРОВАТЬ: На самом деле, если вы собираетесь инкапсулировать каждое свойство объекта, которое хотите представить, я бы рекомендовал вместо этого связать компоненты пользовательского интерфейса с компонентом поддержки, а затем внедрить содержимое непосредственно в значение компонента .

С точки зрения структуры бинов поворотным моментом для меня стало то, что я принудительно проигнорировал все, что я знал о создании веб-приложений, и вместо этого начал рассматривать его как приложение с графическим интерфейсом. JSF имитирует Swing, и поэтому лучшие практики для разработки приложений Swing в основном применимы и к созданию приложений JSF.

Answer 3

Я думаю, что самое важное с вашими бобами - разделить их логику. Если у вас есть первая страница для системы CMS, я бы посчитал плохой практикой помещать каждый фрагмент кода в один компонент, потому что:

1. Боб в конечном итоге станет очень большим
2. Другим людям легче найти то, что они ищут, если они устраняют неполадки на странице входа в систему, если они могут легко найти файл loginBean.java.
3. Иногда у вас есть небольшие кусочки функциональности, которые явно отличаются от остальной части вашего кода, и, отделяя это, я бы подумал, что вам будет проще перестроить / развернуть этот код в нечто большее, когда у вас уже есть хороший боб с хорошей структурой.
4. Имея 1 большой bean-компонент, все это сделает его более зависимым от памяти, если / когда вам придется делать объявления, подобные этому MyBigBean bigBean = new MyBigBean (); вместо того, чтобы использовать funksjonality, который вам действительно нужен, используя LoginBean loginBean = new LoginBean (); (Поправьте меня, если я здесь не прав ???)
5. По моему мнению, разделение ваших бинов похоже на разделение ваших методов. Вам не нужен 1 большой метод, который запускает более 100 строк, а лучше разделить его с помощью новых методов, которые выполняют их конкретные задачи.
6. Помните, что, скорее всего, кому-то, кроме вас, придется работать над вашими проектами JSF.

---

Что касается связывания, я не вижу проблематичной возможности позволить вашим страницам JSF обращаться к свойствам объектов вашего бэк-бина. Это поддержка, встроенная в JSF, которая на самом деле облегчает чтение и сборку imo. Вы уже строго разделяете логику MVC. Делая это, вы экономите тонны линий с помощью геттеров и сеттеров в своем бэкане. Например, у меня есть действительно огромный объект, данный мне веб-сервисами, где мне нужно использовать некоторые свойства в моей презентации. Если бы я должен был создать метод получения / установки для каждого свойства, мой компонент расширился бы еще как минимум на 100 строк переменных и методов для получения свойств. Благодаря встроенной функциональности JSF мое время и драгоценные строки кода экономятся.

Только мои 2 цента по этому поводу, даже если вопрос уже помечен как ответ.

Answer 4

Мне не нужно хранить только один компонент на странице. Это зависит от функциональности, но большую часть времени у меня был один бин на страницу, так как в основном одна страница обрабатывает одну функциональность. Например, на странице у меня есть ссылка для регистрации (я свяжусь с RegisterBean) и ссылка на корзину покупок (ShoopingBasketBean).

Я использую это <: outputText value = "# {myBean.anObject.anObjectProperty}" />, поскольку я обычно сохраняю бины как бины действия, которые содержат объект данных. Я не хочу писать оболочку в своем компоненте поддержки для доступа к свойствам моих объектов данных.

Answer 5

Я, возможно, не отвечу на все ваши вопросы, потому что, похоже, мало кто зависит от конкретного случая.

• Это хорошо, если иметь бизнес-логику в вашем бине. Это зависит от того, откуда ты. Если вы практикуете проектирование на основе предметной области, у вас будет соблазн включить бизнес-логику в компонент поддержки или может быть логикой персистентности. Они утверждают, что почему такой тупой объект. Объект должен нести не только состояние, но и поведение. С другой стороны, если вы рассматриваете традиционный способ выполнения действий в Java EE, у вас может возникнуть ощущение, что вы должны иметь данные в своем компоненте поддержки, который также может быть вашим компонентом управления сущностями, и другую логику ведения бизнеса и персистентности в каком-либо компоненте сеанса или что-то еще. Это тоже хорошо.

• Прекрасно иметь один боб для всей страницы. Я не вижу никаких проблем с этим одним. Это может выглядеть неправильно, но это зависит от случая.

• Ваш другой вопрос гораздо больше зависит от случая, когда вы держите в руках. Я бы предпочел использовать здесь домен, возможно, было бы целесообразно добавить свойства к существующему или иным образом создать новый компонент для этого. Который когда-либо подходит лучше. Я не думаю, что для этого есть какая-то серебряная пуля.

• Каким свойствам принадлежит какой боб. Ну разве это не зависит от предметной области? Или, может быть, вопрос не так ясен.

Более того, в приведенном вами примере кода я не вижу большой выгоды.

Answer 6

Мне нравится тестировать бизнес-код без View, поэтому я рассматриваю BackingBeans как интерфейсы из кода View в код модели. Я никогда не помещал никаких правил или процессов в BackingBean. Этот код входит в службы или помощники, что позволяет использовать повторно.

Если вы используете валидаторы, уберите их из BackingBean и сослаться на них из вашего метода валидации.

Если вы обращаетесь к DAO для заполнения Selects, Radios, Checkbox, делайте это всегда из BackingBean.

Поверь мне! Вы можете внедрить JavaBean в BackingBean, но попытаться внедрить BackingBean в другой. Вскоре вы будете в большом количестве кода обслуживания и понимания.