JSF2 - поддерживается EJB или ManagedBean?

Question

Изучая JSF2, я понял, что не уверен, какими должны быть резервные компоненты.С точки зрения дизайна, в чем разница между EJBS и @ManagedBeans?

В конце концов, я собираюсь использовать JPA, так что EJB - естественный выбор для бизнес-уровня.Является ли хорошей практикой использовать EJB непосредственно из JSF (как объяснено здесь)?

На данный момент я склоняюсь к использованию @ManagedBeans для компонентов, которым не нужен доступ к бизнес-уровню (напримерпросматривать помощников) или обрабатывать данные запроса / сеанса.Для других целей, напримерперечисляя что-либо в сетке, я бы напрямую обращался к EJB.

Хороший ли это дизайн?Должен ли я использовать @ManagedBeans для всех вспомогательных компонентов ради чистого разделения слоев, даже если в некоторых случаях они делегируются только EJB?

Answer 1

Очень правильный вопрос, но я предполагаю, что ответ зависит от "строгости" подхода к вашему проекту.Действительно, существует некоторая избыточность между вспомогательным компонентом JSF и EJB, поскольку оба реализуют некоторую бизнес-логику.

В идеальный вариант использование функций JSF с converters, rendered, validator, и т.д.вспомогательный компонент мог бы действительно, это должен быть чистый код бизнес-логики.Но на практике в нем часто просачивается некоторая логика, связанная с презентацией.

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

Однако унифицированная компонентная модель имеет некоторые преимущества.И это подход, принятый Шов и Весна.В обоих случаях бизнес-компонент с декларативной транзакцией и т.д.может использоваться непосредственно в JSF (Spring не использует EJB, но предоставляет аналогичную модель).Пурист EJB, однако, сказал бы, что вы должны отделить их друг от друга.

Так что для меня это в конечном счете вопрос вкуса и размера проекта.Я могу себе представить, что для небольшого / среднего проекта использование EJB в JSF работает нормально.Для более крупного проекта, где эта строгость критична, убедитесь, что вы не перепутали слои.

Answer 2

В Java EE 6 существует некоторое перекрытие между различными управляемыми компонентами:Управляемые компоненты JSF (@ManagedBean), управляемые компоненты CDI (@Named) и компоненты EJB (@Stateless, @Statefull, @Singleton).

В слое просмотра я не вижу никакого особого преимущества в использовании @ManagedBean.Вариант CDI @Named, похоже, способен делать то же самое и даже больше, напримерпредоставить вам доступ к области преобразования.

Текущее мышление, по-видимому, заключается в том, что в конечном итоге компонентная модель EJB также будет модифицирована в виде набора аннотаций CDI.Особенно член экспертной группы Реза Рахман часто намекает на это.Смотрите , например , Внедрение зависимостей в Java EE 6 - Часть 1

На данный момент этого не произошло, поэтому компоненты EJB остаются самым простым местом для размещения бизнес-логики, особенно когда JPA используется для сохранения.

Тем не менее, независимо от того, получит CDI возможности EJB или нет, ИМХО, по-прежнему рекомендуется использовать отдельный компонент для концепции "резервного компонента" и отдельный компонент для "бизнес-логики".

Вспомогательный компонент может быть действительно тонким, просто содержать некоторые ссылки на объекты модели и сервисы (EJBS).Методы действий вспомогательного компонента могут делегироваться службам практически напрямую, но их дополнительная ценность заключается в предоставлении пользователю обратной связи (добавление FacesMessages в случае успеха или неудачи) и внесении небольших изменений в пользовательский интерфейс (напримерустановка логического значения в false, при котором отображалось какое-либо диалоговое окно).

Службы (бизнес-логика) не должны ничего знать о какой-либо конкретной презентации.Они должны быть одинаково хорошо использованы из вспомогательных компонентов JSF, JAX-RS, сервлетов, автономных удаленных клиентов Java SE или чего-либо еще.

Даже если все компоненты станут компонентами CDI, то это не изменит этого базового разделения ответственности.

Answer 3

Интересная статья, не знал об этом.Однако, на мой взгляд, эта статья больше смахивает на разглагольствования в адрес управляемых компонентов JSF.Это также жестко связывает EJB с JSF.Возможно, это интересно в небольших (персональных) приложениях, но, скорее всего, не в реальных SOA-приложениях, где вы хотели бы иметь полный контроль над обслуживаемым EJB.

Что касается того, какой из них использовать для чего, я бы просто придерживался @ManagedBean для обозначения модели JSF, которая привязана к одному или нескольким конкретным представлениям JSF.Вы можете прекрасно использовать @EJBs для бизнес-логики, не относящейся к JSF, и /или моделей данных.Вы можете сделать инъекцию @EJBs в модели JSF и делегируйте ее в методах действия и, возможно, также в получателях / установщиках, но вы не должны делать наоборот, т.е.не определяйте модель JSF в @EJB, это приводит к плотному сцеплению и сделало бы @EJBs непригоден для использования вне контекста JSF.Что касается вашего дизайна, то он звучит неплохо, при условии, что вы следите за тем, чтобы ничего не импортировать из javax.faces посылка в @EJB класс.

Answer 4

Вызывая EJB из вашего XHTML, вы вводите тесную связь между выбором реализации в представлении и бизнес-уровнем.

Если вы используете управляемый компонент для вызова EJB [или даже добавляете бизнес-делегата], вы сможете полностью изменить свой бизнес-уровень на Spring, не затрагивая уровень представления (XHTML).

Это технически возможно и очень просто для вас (JSR 299) иметь возможность использовать EJB в качестве управляемого компонента, и, вероятно, именно этого хотят от вас эти поставщики - придерживаться специфики.Но правильно ли это делать?- Нет.