JSF2 - поддержанный EJB или ManagedBean?
Поскольку я изучаю JSF2, я понял, что я не уверен, каковы отступающие компоненты должны быть. С точки зрения дизайна, каково различие между EJBs и @ManagedBeans?
В конце я собираюсь использовать JPA, таким образом, EJB является естественным выбором для бизнес-слоя. Действительно ли это - хорошая практика для использования EJB непосредственно от JSF (как объяснено здесь)?
В данный момент я склоняюсь к использованию @ManagedBeans для компонентов, которые не нуждаются в доступе к бизнес-слою (например, просматривают помощников) или имеют дело с данными запроса/сессии. В других целях, например, списке чего-то в сетке, я непосредственно получил бы доступ к EJB.
Действительно ли это - хороший дизайн? Я буду использовать @ManagedBeans для всех бобов поддержки ради чистого разделения слоя, даже если в некоторых случаях они только делегируют к EJB?
2 ответа
Очень правильный вопрос, но я полагаю, что ответ зависит от "строгости" подхода для вашего проекта. Между JSF backing bean и EJB действительно есть некоторая избыточность, поскольку оба реализуют некоторую бизнес-логику.
В идеальном использовании возможностей JSF с конвертерами, рендерингом, валидатором и т.д. backing bean мог бы действительно быть чистым кодом бизнес-логики. Но на практике в него часто просачивается логика, связанная с представлением.
Эта логика, связанная с представлением, в идеале не должна находиться в EJB. Эта логика, связанная с представлением, может зависеть от пакета лиц, но не обязательно. Именно то, что она делает, делает ее презентационной или нет.
Унифицированная модель компонентов все же имеет некоторые преимущества. И именно такой подход используют Seam и Spring. В обоих случаях бизнес-компонент с декларативной транзакцией и т.д. может быть использован непосредственно в JSF (Spring не использует EJB, но предоставляет похожую модель). Пурист EJB, однако, сказал бы, что вы должны разделить эти два понятия.
Так что для меня это, в конечном счете, вопрос вкуса и размера проекта. Я могу представить, что для небольшого/среднего проекта использование EJB в JSF работает отлично. Для более крупного проекта, где эта строгость критична, убедитесь, что вы не испортите слои.
Интересная статья, не знал об этом. Однако для меня эта статья больше пахнет тирадой в адрес управляемых компонентов JSF. Он также тесно связывает EJB с JSF. Это может быть интересно в небольших (личных) приложениях, но, скорее всего, не в реальных SOA-приложениях, где вы хотели бы иметь полный контроль над обслуживаемыми EJB-компонентами.
Что касается того, что использовать для чего, я бы просто придерживался @ManagedBean , чтобы обозначить модель JSF, которая привязана к одному или нескольким конкретным представлениям JSF. Вы можете идеально использовать @EJB для бизнес-логики и / или моделей данных, не относящихся к JSF. Вы можете ввести @EJB в модель JSF и делегировать его в методах действий и, возможно, также в геттерах / установщиках, но вы не должны делать наоборот, т.е. не определять модель JSF в @EJB , это приводит к сильной связи и делает @EJB непригодным для использования вне контекста JSF. Пока что ваш дизайн звучит хорошо, если вы следите за тем, чтобы ничего не импортировать из пакета javax.faces в класс @EJB .