Поддержка бобов (@ManagedBean) или CDI-бинов (@Named)

Question

Я только начал читать через Core JavaServer Faces, 3-е изд. , и они говорят это (выделение мое):

Это историческая случайность, когда есть два отдельных механизма, CDI bean и управляемые компоненты JSF для компонентов, которые могут использоваться на страницах JSF. Предлагаем что вы используете компоненты CDI , если ваше приложение не должно работать на простом сервлете бегун, такой как Tomcat.

Почему? Они не дают никакого оправдания. Я использовал @ManagedBean для всех bean-компонентов в прототипе приложения, работающего на GlassFish 3, и я не заметил каких-либо проблем с этим. Я не особо против перехода с @ManagedBean на @Named, но я хочу знать , почему я должен беспокоиться .

Answer 1

Использовать CDI.

Согласно JSF 2.3, @ManagedBean равно устарело .См. Также спецификация 1417 .Это означает, что больше нет причин выбирать @ManagedBean вместо @Named.Впервые это было реализовано в бета-версии Mojarra 2.3.0 m06.

---

История

Разница в ядре: @ManagedBean управляется средой JSF и доступна только через @ManagedProperty для других управляемых компонентов JSF.@Named управляется сервером приложений (контейнером) через инфраструктуру CDI и через @Inject доступна для любого типа управляемого артефактом контейнера, например @WebListener, @WebFilter@WebServlet, @Path, @Stateless и т. Д. И даже JSF @ManagedBean.С другой стороны, @ManagedProperty не работает внутри @Named или любого другого управляемого артефактом контейнера.На самом деле он работает только внутри @ManagedBean.

Другое отличие состоит в том, что CDI фактически внедряет прокси, делегирующие текущему экземпляру в целевой области, для каждого запроса / потока (например, как EJB-компоненты были внедрены).Этот механизм позволяет внедрить компонент с более узкой областью действия в компонент с более широкой областью действия, что невозможно с JSF @ManagedProperty.JSF «внедряет» сюда физический экземпляр напрямую, вызывая установщик (это также точно, почему требуется установщик, в то время как не требуется с @Inject).

Хотя это и не напрямуюнедостаток - есть и другие способы - область применения @ManagedBean просто ограничена.С другой стороны, если вы не хотите показывать «слишком много» для @Inject, вы также можете просто оставить свои управляемые компоненты @ManagedBean.Это как protected против public.Но это на самом деле не считается.

По крайней мере, в JSF 2.0 / 2.1 основным недостатком управления компонентами JSF, поддерживающими CDI, является отсутствие CDI-эквивалента @ViewScoped.@ConversationScoped подходит близко, но все же требует ручного запуска и остановки и добавляет к исходным URL-адресам ужасный параметр запроса cid.MyFaces CODI делает это проще благодаря прозрачной привязке JSF javax.faces.bean.ViewScoped к CDI, так что вы можете просто сделать @Named @ViewScoped, однако, который добавляет некрасивый параметр запроса windowId к конечным URL-адресам, в том числе при простой навигации по страницам. OmniFaces решает все это с истинным CDI @ViewScoped, который действительно связывает область действия компонента с состоянием представления JSF вместо произвольного параметра запроса.

JSF 2.2 (который выпускается через 3 года после этого вопроса / ответа) предлагает новую полностью совместимую с CDI аннотацию @ViewScoped из коробки с ароматом javax.faces.view.ViewScoped.JSF 2.2 даже поставляется с CDI-@FlowScoped, который не имеет эквивалента @ManagedBean, тем самым подталкивая пользователей JSF к CDI.Ожидается, что @ManagedBean и друзья будут устаревшими согласно Java EE 8. Если вы все еще используете @ManagedBean, поэтому настоятельно рекомендуем переключиться на CDI, чтобы подготовиться к будущим путям обновления.CDI легко доступен в контейнерах, совместимых с веб-профилем Java EE, таких как WildFly, TomEE и GlassFish.Для Tomcat вы должны установить его отдельно, точно так же, как вы уже сделали для JSF.См. Также Как установить CDI в Tomcat?

Answer 2

CDI предпочтительнее простого JSF, потому что CDI допускает внедрение зависимостей в масштабе JavaEE.Вы также можете вводить POJO и управлять ими.С JSF вы можете вводить только часть того, что вы можете с помощью CDI.

Answer 3

С Java EE 6 и CDI у вас есть другая опция для управляемых компонентов

• @javax.faces.bean.ManagedBean относится к JSR 314 и было введено с JSF 2.0. Основная цель состояла в том, чтобы избежать настройки в файле Face-config.xml для использования bean-компонента внутри JSF-страницы.
• @javax.annotation.ManagedBean(“myBean”) определяется JSR 316. Он обобщает управляемые компоненты JSF для использования в других местах в Java EE
• @javax.inject.Named(“myBean”) почти такие же, как и выше, за исключением того, что вам нужен файл beans.xml в папке web / WEB-INF для активации CDI.

Answer 4

Я использовал CDI в GlassFish 3.0.1, но чтобы заставить его работать, мне пришлось импортировать фреймворк Seam 3 (Weld).Это сработало довольно хорошо.

В GlassFish 3.1 CDI перестал работать, и Seam Weld перестал с ним работать.Я открыл ошибку на этом , но пока не видел ее исправленной.Мне пришлось преобразовать весь мой код в аннотации javax.faces. *, Но я планирую вернуться к CDI, как только он заработает.

Я согласен, что вы должны использовать CDI, но у меня нет одной проблемыпока не решено, что делать с аннотацией @ViewScoped.У меня много кода, который зависит от этого.Не ясно, работает ли @ViewScoped, если вы не используете @ManagedBean с ним.Если кто-то может уточнить это, я был бы признателен.

Answer 5

Одна веская причина для перехода на CDI: у вас может быть общий ресурс в области сеанса (например, профиль пользователя) @Inject, объединенный как с управляемыми компонентами JSF, так и с сервисами REST (т. Е. Jersey / JAX-RS).

С другой стороны, @ViewScoped - убедительная причина придерживаться JSF @ManagedBean - особенно для всего, что имеет значительный AJAX.В CDI нет стандартной замены для этого.

Кажется, что он может иметь некоторую поддержку @ViewScoped -подобной аннотации для bean-компонентов CDI, но я не играл с ней лично.

http://seamframework.org/Seam3/FacesModule