Смущает: роль бобов в JSF2 по сравнению с классическими контроллерами MVC - PullRequest
2 голосов
/ 24 января 2012

У меня есть вопрос, который больше связан с дизайном и архитектурой. Я родом из классического MVC-опыта и должен запачкать руки на JSF2. Я читаю статьи IBM о JSF2 (http://www.ibm.com/developerworks/library/j-jsf1/) и думаю, что понимаю общую концепцию.

Я начал связываться с JSF2 через ROO. У меня такое ощущение, что ROO (возможно, это верно для любого приложения типа JSF2, а может и нет) очень странно / нечетко использует бины. В общем, мне действительно не ясно, какова реальная роль Боба! Например, если у меня есть представление с формой, предназначенной для редактирования одной пользовательской записи, я инициализирую пользователя в a, давайте назовем его UserBean (возможно, сохранить в переменной-члене) и получить доступ к этой переменной через геттеры. Если я теперь хочу просмотреть всех пользователей, я бы снова отобразил представление в UserBean, содержащее коллекцию пользователей, и снова получил бы доступ к этой коллекции через геттеры. Предыдущее описание на самом деле так, как я бы делал вещи с JSF. Это означает, что я бы использовал UserBean больше как statefull-сервис в качестве контроллера.

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

Я часто пользуюсь услугами, специфичными для контекста, например, если я часто обращаюсь к пользователю и распространяю его по приложению, я создаю пользовательский сервис, который обрабатывает специфичную для пользователя логику, которую, возможно, сложно поместить в саму себя. Если бы я сейчас, например, посмотрел на сгенерированные Roo Beans, я бы нашел методы, которые программно отображают формы, поля ввода, метки, которые снова хранят списки пользователей, логические поля, которые указывают, были ли данные уже загружены, однопользовательские элементы и множество методы, которые больше похожи на то, чтобы быть помещенными в UserService (или что-то еще). Мне интересно, так ли это предназначено для использования JSF2, на словах: помещать в bean все, что связано с одним контекстом, не использовать сервис и писать «суперконтроллерные компоненты», которые обрабатывают все?

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

  1. очень примерный и заслуживающий одобрения пример приложения, которое использует bean-компоненты таким образом, как они были предназначены для использования в сочетании с функциями и сценариями jsf2, которые, например, реализуют базовые сценарии использования CRUD вокруг объекта данного типа. (Один большой запутанный момент заключается в том, что в моем случае ROO всегда использует AJAX и javascript, такие как Modal-Dialogs, для реализации логики CRUD. Интересно, есть ли в JSF более классический способ для этого? [С 'classic' я например, для представлений на основе URL и отдельных представлений для просмотра, редактирования и просмотра объектов])
  2. ресурс, который просвещает типичные JSF-паттерны "все, что надо, ребята, сделай это" (может быть, это J2EE-паттерны?).

Большое вам спасибо!

Пожалуйста, не стесняйтесь подтолкнуть меня к конкретизации конкретных моментов, если я не уверен!

1 Ответ

2 голосов
/ 24 января 2012

Ссылка для JSF2, которую вы опубликовали, указывает на статью JSF1.2. Если вы хотите начать с JSF2 или JSF, я предлагаю следующие ссылки.

Я предлагаю начать с простого ванильного JSF, а не ROO с JSF, чтобы освоить JSF.

Чтобы ответить на ваш вопрос

  • Первая ссылка предоставляет вам простые примеры jsf, в JSF вы можете использовать как ajax, так и классический способ отправки формы. В версиях JSF 1.x ajax не был неотъемлемой частью JSF, он был реализован сторонней библиотекой компонентов, в основном RichFaces и PrimeFaces, и это лишь некоторые из них. В JSF2 есть встроенная поддержка ajax, это не касается сторонних компонентов, больше не требуется, они все еще предоставляют некоторые расширенные функции. Я предлагаю перейти по этой ссылке , чтобы найти различия между JSF 1.x и JSF 2.
  • Шаблоны, о которых я не знаю, такие как специфические для JSF, кроме кода, могут быть классифицированы в модели - представление - контроллер. В типичном случае Person представляет модель, PersonMangedBean выполняет роль контроллера, который играет центральную роль в получении данных из представления (jsp / facelets), и после обработки данных в самом bean-компоненте или служебных компонентах, которые обрабатывают переход к классическим представлениям, может быть listPersons.xhtml.
  • Управляемые компоненты JSF не являются "суперконтроллерными компонентами", обрабатывающими каждую вещь в этом компоненте. Я пытаюсь распределить вещи по категориям так, как вы упомянули, т. Е. У вас есть сервисный уровень, где вся наша бизнес-логика может быть EJB или Spring-управляемым bean-компонентом, и это по крайней мере отделяет бизнес-логику от технологии представления JSF, благодаря чему ее (сервис) можно использовать где-то еще. как библиотека, если она спроектирована правильно.
  • Подсказка: JSF - это основанная на компонентах инфраструктура, а не основанная на действиях, и у нее есть собственный жизненный цикл, поэтому овладение этим жизненным циклом сэкономит много времени и правильное понимание структуры. Эта ссылка , хотя для JSF 1.x подходит и для JSF2, для базового понимания жизненного цикла.

Надеюсь, это поможет.

...