Поддержка JSF bean (лучшие практики)

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

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

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

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

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

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

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

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

с поддержкой bean значения:

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

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

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

ОТВЕТЫ

Ответ 1

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

Ниже приведено описание различных типов bean, как определено в приведенной выше статье Нила Гриффина:

  • Управляемая модель Bean. Обычно область сеанса. Этот тип управляемого bean участвует в "Моделировании" модели проектирования MVC. Когда вы видите слово "модель" - подумайте DATA. Модель JSF - bean должна быть POJO, которая следует за шаблоном проектирования JavaBean с инкапсулирующими свойствами геттеров/сеттеров. Наиболее распространенным вариантом использования для модели bean должен быть объект базы данных или просто представлять набор строк из набора результатов запроса к базе данных.
  • Резервное копирование управляется Bean. Обычно запрашивает область. Этот тип управляемого bean участвует в заботе "Вид" шаблона проектирования MVC. Цель поддержки bean заключается в поддержке логики пользовательского интерфейса и имеет соотношение 1:: 1 с представлением JSF или форму JSF в композиции Facelet. Хотя он, как правило, обладает свойствами стиля JavaBean со связанными getters/seters, это свойства представления, а не модели данных базового приложения. Поддержка JSF-beans может также иметь методы JSF actionListener и valueChangeListener.
  • Управляемый управляемый Bean. Обычно запрашивает область. Этот тип управляемого bean участвует в решении "Контроллер" шаблона проектирования MVC. Назначение контроллера bean заключается в выполнении какой-либо бизнес-логики и возвращении результата навигации в навигатор JSF. JSF-контроллер beans обычно имеет методы JSF-действий (а не методы actionListener).
  • Поддержка управляемого Bean: обычно сеанс или область приложения. Этот тип bean "поддерживает" одно или несколько видов в представлении "Вид" шаблона проектирования MVC. Типичным примером использования является предоставление списков ArrayList для JSF h: selectOneMenu, которые отображаются в более чем одном представлении JSF. Если данные в раскрывающихся списках относятся к пользователю, то bean будет храниться в области сеанса. Однако, если данные относятся ко всем пользователям (например, к выпадающим спискам провинций), то bean будет храниться в области приложения, так что он может быть кэширован для всех пользователей.
  • Утилита управляемая Bean. Обычно область приложения. Этот тип bean предоставляет некоторую функцию "полезности" для одного или нескольких представлений JSF. Хорошим примером этого может быть FileUpload bean, который может быть повторно использован в нескольких веб-приложениях.

Ответ 2

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

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

EDIT: На самом деле, если вы собираетесь инкапсулировать каждое свойство объекта, которое вы хотите открыть, я бы рекомендовал вам вместо этого привязать компоненты пользовательского интерфейса к резервной копии bean, а затем ввести содержимое непосредственно в значение компонента.

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

Ответ 3

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

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

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

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

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

Кроме того, в вашем примере кода я не вижу огромного преимущества.

Ответ 4

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Если вы используете валидаторы, выложите их из своего BackingBean и ссылайтесь на них с помощью метода проверки.

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

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