JSF backing bean structure (best practices)

Question

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

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

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

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

---

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

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

Я всегда требуется что-то вроде:

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

со значением боба поддержкой:

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

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

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

Answer 1

Возможно, вы захотите это проверить: making distinctions between different kinds of JSF managed beans.

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

---

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

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

Answer 6

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

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

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

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