Структура квасолі JSF (кращі практики)


118

Я сподіваюсь, що в цій публікації я можу отримати думку людей щодо кращих практик інтерфейсу між сторінками JSF та резервними бобами.

Одна річ, на якій я ніколи не можу погодитися - це структура моїх бобів. Крім того, я ніколи не знайшов гарної статті на цю тему.

Які властивості належать до якої підкладки бобів? Коли доцільно додати більше властивостей до даного бобу, на відміну від створення нового боба та додавання до нього властивостей? Чи має сенс для простих застосунків мати лише один резервний боб для всієї сторінки, враховуючи складність введення одного квасолі в інший? Чи повинно містити будь-яка фактична бізнес-логіка або вона суворо містить дані?

Не соромтесь відповідати на ці запитання та будь-які інші, які можуть виникнути.


Що стосується зменшення зв'язку між сторінкою JSF та резервним боком, я ніколи не дозволяю сторінці JSF отримати доступ до будь-яких властивостей резервного боба. Наприклад, я ніколи не дозволяю щось таке, як:

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

Мені завжди потрібне щось на кшталт:

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

зі значенням опорних бобів:

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

Коли я перебираю колекцію над колекцією, я використовую клас обгортки, щоб, наприклад, уникати свердління в об'єкт у таблиці даних.

Взагалі, такий підхід мені здається "правильним". Це дозволяє уникнути будь-якого зв’язку між поданням та даними. Будь ласка, виправте мене, якщо я помиляюся.


Чи можете ви навести приклад: Коли я перебираю цикл на колекцію, я використовую клас обгортки, щоб, наприклад, не уникати свердління в об'єкт у таблиці даних.
Корай Тугай

2
Для отримання додаткової інформації див відповідь BalusC за адресою stackoverflow.com/questions/7223055 / ...
Zack Marrapese

Відповіді:


146

Ви можете перевірити це: розрізняючи різні види квасолі JSF .

Ось опис різних типів квасолі, визначених Нілом Гріффіном у цій статті:

  • Модель Managed-Bean : як правило, область сеансу. Цей тип керованих бобів бере участь у концерні "Модель" моделі MVC. Коли ви побачите слово "модель" - подумайте ДАНІ. Модель JSF-модель повинна бути POJO, що відповідає схемі дизайну JavaBean із властивостями інкапсуляції getters / setters. Найпоширеніший випадок використання для модельного компонента - це об'єкт бази даних або просто представити набір рядків із набору результатів запиту бази даних.
  • Резервне копіювання керованого біна : зазвичай запитуйте область. Цей тип керованих бобів бере участь у концерні "Вид" дизайну MVC. Призначення бек-бін полягає в підтримці логіки інтерфейсу користувача і має відношення 1 :: 1 з поданням JSF або формою JSF у складі Facelet. Хоча зазвичай він має властивості у стилі JavaBean із пов’язаними геттерами / сеттерами, це властивості представлення даних, а не основної моделі даних програми. JSF резервні боби можуть також мати методи JSF actionListener та valueChangeListener.
  • Controller Managed-Bean : Зазвичай область запиту. Цей тип керованих бобів бере участь у концерні "Контролер" схеми дизайну MVC. Призначення контролера - виконувати якусь ділову логіку та повертати результат навігації навігатору JSF. Як правило, у контрольних блоках JSF є методи дії JSF (а не методи actionListener).
  • Підтримка Managed-Bean : Зазвичай сеанс чи область застосування. Цей тип квасолі "підтримує" один або більше поглядів у концерні "Вид" схеми дизайну MVC. Типовим випадком використання є надання ArrayList для JSF h: selectOneMenu спадних списків, які відображаються у більш ніж одному представленні JSF. Якщо дані у випадаючих списках є специфічними для користувача, то боб зберігатиметься в межах сеансу. Однак якщо дані стосуються всіх користувачів (наприклад, випадаючі списки провінцій), то бін зберігатиметься в області застосування, щоб його можна було кешувати для всіх користувачів.
  • Утиліта Managed-Bean : Зазвичай область застосування. Цей тип квасолі забезпечує певний тип функції «корисності» для одного або декількох представлень JSF. Хорошим прикладом цього може бути файл FileUpload, який можна повторно використовувати у кількох веб-додатках.

8
Це чудова стаття. Я ніколи цього не бачив і, безумовно, радий, що ви його опублікували. Хто проголосував за це, божевільний. Це не специфічно для IceFaces.
Зак Маррапез

2
Здається, посилання на фактичну статтю відсутнє.
Білл Росмус

Копію можна знайти тут
ChrLipp

10
Але я не можу дійти до того, що ця відповідь наразі на 71 оскарження. Хто реалізував свою заявку JSF за цими правилами, безсумнівно, після цього повинен бути скандалом на те, що JSF є жахливо непрозорим рамкою, а їхні програми JSF є великим безладом коду, і всі вони звинувачують самого JSF замість власного поганого підходу, заснованого на неправильних уроках та т.зв. "кращі практики" вивчені.
BalusC

чи виконується будь-яка логіка цих бобів у браузері, а не на сервері?
eskalera

14

Чудове запитання. Я багато страждав від тієї ж дилеми, коли перейшов до JSF. Це дійсно залежить від вашої заявки. Я з світу Java EE, тому я рекомендую мати якомога менше ділової логіки у ваших підкладках. Якщо логіка суто пов'язана з презентацією вашої сторінки, то цілком добре мати її в підкладці.

Я вважаю, що однією з (безлічі) сильних сторін JSF є насправді той факт, що ви можете виставляти об’єкти домену безпосередньо на керованих бобах. Тому я б настійно рекомендував цей <:outputText value="#{myBean.anObject.anObjectProperty}" />підхід, інакше ви в кінцевому підсумку робите занадто багато роботи для ручного викриття кожної властивості. Крім того, якщо вставити або оновлювати дані, було б безладно, якщо ви інкапсулювали всі властивості. Бувають ситуації, коли одного об’єкта домену може виявитися недостатньо. У цих випадках я готую ValueObject, перш ніж виставляти його на квасоля.

EDIT: Насправді, якщо ви збираєтесь інкапсулювати кожне властивість об'єкта, яке ви хочете викрити, я рекомендую замість цього прив’язати компоненти інтерфейсу до резервного боба, а потім ввести вміст безпосередньо у значення компонента.

З точки зору структури квасолі переломним моментом для мене став той факт, коли я насильно ігнорував усі речі, які я знав про створення веб-додатків, а замість цього почав ставитися до цього як до GUI-програми. JSF імітує багато Swing, і тому найкращі практики розробки додатків Swing в основному також стосуватимуться побудови програм JSF.


Дякуємо за ваше розуміння. Я ніколи насправді не робив багато на шляху розгортання заявок (крім академічних проектів давно). Які є хороші принципи розмахуючих додатків? Крім того, чому це безлад під час вставки та оновлення значень? мені здається те саме?
Зак Маррапез

5

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

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


Що стосується з’єднання, я не вважаю це проблемою, що дозволяє вашим сторінкам JSF отримати доступ також до властивостей об'єктів на вашій основі. Ця підтримка вбудована в JSF і насправді просто полегшує читання та створення imo. Ви вже чітко розділяєте логіку MVC. Роблячи це, ви заощадите тонни ліній з геттерами та сетерами на вашому базі. Наприклад, у мене дійсно величезний об’єкт, наданий мені веб-службами, де мені потрібно використовувати деякі властивості у своїй презентації. Якби я створив геттер / сеттер для кожної властивості, мій боб би розширився принаймні на 100 рядків змінних та методів отримання властивостей. Використовуючи вбудовану функціональність JSF, ми заощаджуємо час та дорогоцінні кодові рядки.

Щойно мої 2 копійки з цього приводу навіть із запитанням, яке вже було позначене як відповідь.


1
однак, якщо у вас є величезний предмет, який сидить у вашій квасолі, і у вас, скажімо, - 15 EL функцій, копаючи в цей об’єкт зі сторінки JSF, ви тепер прив'язані не тільки до бобів, але до цього об'єкта. Тому видалити цей об’єкт буде важко, не порушуючи інтерфейс користувача.
Зак Маррапез

1
Але ви не хочете, щоб ваша підкладка була прив’язана до цього предмета? А ваш інтерфейс користувача прив’язаний до підкладки? Коли вам доведеться це змінити, вам доведеться змінити всі ваші getters / setters як в інтерфейсі, так і в bean.
Кріс Дейл

4

Я не можу відповісти на кожне ваше запитання, тому що мало хто здається цілком залежним від конкретного випадку.

  • Це добре, щоб у вашій підставці була ділова логіка. Це залежить, звідки ви родом. Якщо ви практикуєте дизайн, орієнтований на домен, ви будете спокушені включити бізнес-логіку до резервної фасолі або, можливо, буде і логікою постійності. Вони стверджують, що чому такий німий предмет. Об'єкт повинен нести не лише стан, але й поведінку. З іншого боку, якщо ви розглядаєте традиційний спосіб виконання Java EE, вам може здатися, що у вашому резервному бобі є дані, які також можуть бути вашим об'єктом, а також іншою логікою бізнесу та наполегливості в якомусь сеансовому бобі чи щось. Це теж добре.

  • Це абсолютно добре, щоб мати єдину підкладку для всієї сторінки. Я не бачу жодної проблеми з цим поодинці. Це може здатися не правильним, але це залежить від конкретного випадку.

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

  • Які властивості належать до якої підкладки. Ну хіба це не залежить від об’єкта домену? Або питання може бути не таким зрозумілим.

Більше того, у вашому прикладі даного коду я не бачу великої користі.


якби, наприклад, ми мали перейти від використання POJO, створених в домашніх умовах, створених за допомогою JDBC-запитів, до сплячих об'єктів, які мали дещо інші назви полів, нам довелося б не лише змінити резервну частину. Ми повинні також змінити сторінку JSF. Не так у моєму прикладі коду. Просто поміняйте квасоля.
Зак Маррапез

У такому випадку ви можете зробити свою підкладку, сутність. тоді вам потрібно просто змінити сторінки JSF. Або це залежить від того, чому б ви все-таки змінили назву властивостей? це матиме сенс лише при перейменуванні поля на відповідність імені стовпця бази даних. Але це зовсім інший випадок.
Адель Ансарі

4

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

Я використовую це <: outputText value = "# {myBean.anObject.anObjectProperty}" />, як я зазвичай зберігаю резервні боби як квасоля дії, що містить об'єкт даних. Я не хочу писати обгортку в резервну частину для доступу до властивостей моїх даних.


0

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

Якщо ви використовуєте валідатори, вийміть їх із BackingBean і посилайте їх на свій метод перевірки.

Якщо ви отримуєте доступ до DAO для заповнення вибору, радіостанцій, прапорців, робіть це завжди поза BackingBean.

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

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.