Являются ли @ManagedBeans устаревшими в JavaEE6 из-за @Named в CDI/Weld?

Из-за CDI (и его реализации Weld) каждый POJO в JEE6 может быть аннотирован с помощью @Named, что делает POJO доступным для представления.

Означает ли это, что ManagedBeans теперь полностью устарели? Или я пропустил что-то, где @ManagedBean все еще имеет смысл?

Ответы

Ответ 1

Короче говоря, @ManagedBean имеет смысл для приложений, которые используют JSF, но не используют JSR 299 (независимо от причины). Ниже более подробное объяснение от Гевина Кинга:

Re: Сравнение с аннотациями @ManagedBean в JSF2?:

При просмотре примеров Weld и старых WebBeans   документации, это выглядит как   конкурент нового JSF @ManagedBean   2.0 аннотации. Есть ли информация о том, когда мы хотим использовать   один над другим?

Это хороший вопрос, и я не действительно в полном согласии с ответы, которые были опубликованы до сих пор.

Новая управляемая EE спецификация Beansопределяет модель базового компонента для Java EE, а также очень простой набор контейнерных услуг (@Resource, @PostConstruct, @PreDestroy).

Идея заключается в том, что другие спецификации (начиная с EJB, CDI, JSF и новые спецификации перехватчиков Java) эта базовая модель и слой дополнительные услуги, например управление транзакциями, типы инъекции зависимостей, перехватчики. Так на этом уровне управляемые beans, CDI, перехватчики и спецификации EJB все работают рука об руку и очень дополняют друг друга.

Теперь управляемая Beans спецификация полностью закрыта по отношению к определение того, какие классы управляемый beans. Он обеспечивает @ManagedBean аннотация как одна механизм, но он также позволяет другим спецификации для определения разных механизмы. Итак, например:

  • В спецификации EJB говорится, что класс, подчиняющийся определенному программированию ограничения с помощью @Stateless или @Stateful аннотация, развернутая в Ячейка EJB управляется bean.

  • В спецификации CDI говорится, что любой класс с соответствующим конструктором развертывается в развертывании beanархив "является управляемым bean.

Учитывая, что EJB и CDI обеспечивают возможно, более удобные способы идентифицировать управляемый bean, вы можете интересно, что такое @ManagedBeanнеобходимо для. Ответ, как указано в Дан, это то, что если у вас есть CDI доступный в вашей среде (для Например, если вы используете EE6), то @ManagedBean просто не очень необходимо. @ManagedBean действительно там для использования людьми, использующими JSF2 без CDI.

OTOH, если вы выполните аннотацию bean @ManagedBean, и у вас есть CDI в вашей среды, вы все равно можете использовать CDI для ввода материала в ваш bean. Просто, что @ManagedBeanаннотация в этом не требуется. случай.

Подводя итог, , если у вас есть CDI доступный вам, он обеспечивает лучшей модели программирования для @ManagedBean/@ManagedProperty модель что JSF2 наследует от JSF1. Так на самом деле, что EE 6 web профиль не требует поддержки @ManagedProperty и т.д. Идея что вы должны просто использовать CDI.

Ответ 2

У вас есть выбор. Либо используйте @ManagedBean из JSF2 для привязки beans к вашим формам, либо используйте аннотацию @Named из CDI. Если вы планируете только делать JSF, вы можете придерживаться @ManagedBean, но если вы хотите интегрироваться с EJB или использовать CDI @ConversationScoped, перейдите по пути CDI.

Лично я считаю, что следующая версия JSF должна обесценить @ManagedBean и стандартизировать CDI. Двойственность путается с новичками.

Ответ 3

CDI не имеет видимой области видимости, потому что не имеет понятия представления, поэтому, если вам нужна эта область, CDI в чистом виде не может сделай это. Область просмотра в основном означает область запроса + готовность AJAX. Это не представление JSF, например, страница с именем xyz.xhtml, даже если вы видите JSF <f:viewParam> и подобные. Частый прецедент с beans с видимым охватом - это как получить параметры GET в такой bean. Также прочитайте это.

Обратите внимание, что CDI скорее живет на уровне EJB/service, чем на уровне JSF/presentation. Этот блог имеет хороший обзор.

Как таковой @ManagedBean нельзя полностью заменить CDI, опять же, если вы используете @ViewScoped beans - по крайней мере, не без расширение CDI или используя Модуль Seam 3 Faces. Использование области видимости beans почти всегда будет происходить при использовании наборов GUI на базе AJAXed JSF 2, таких как RichFaces, PrimeFaces, IceFaces и т.д.

Смешивание аннотаций с неправильными пакетами Java EE 6 может вызвать у вас неприятности неожиданно, снова при использовании RichFaces или аналогичного API:

@javax.faces.bean.ManagedBean
@javax.faces.bean.[Jsf]Scoped

для компонентов, используемых исключительно на уровне презентации, здесь RichFaces, PrimeFaces и т.д. Некоторые богатые компоненты кажутся проблемы с CDI-аннотированным и JSF-аннотированным помощником beans. Если вы получаете странное поведение от вашего beans (или beans, который ничего не делает), причиной может быть неправильное сочетание аннотаций.

Смешивание JSF и CDI, например

@javax.inject.Named
@javax.faces.bean.[Jsf]Scoped

возможно и работает в большинстве случаев при ссылке со страниц JSF, однако есть некоторые малоизвестные проблемы/недостатки, например. когда использует область JSF, у которой CDI не имеет:

Также комбинация @Named @ViewScoped не будет работать должным образом. JSF-специфический @ViewScoped работает только в сочетании с JSF-специфическим @ManagedBean. Ваш CDI-специфичный @Named будет вести себя как @RequestScoped таким образом. Либо используйте @ManagedBean вместо @Named, либо используйте CDI-специфический @ConversationScoped вместо @ViewScoped.

Тогда

@javax.inject.Named
@javax.faces.bean.[Cdi]Scoped

может использоваться для CDI beans, непосредственно связанного с вашими страницами JSF AFAIK. До сих пор у меня не было никаких проблем с вышеупомянутыми комбинациями, поэтому вы могли бы считать @ManagedBean устаревшим здесь.

То, что осталось, это уровень сервиса, здесь в основном транзакционная служба EJB beans объявлена ​​как

@javax.ejb.*

в основном @javax.ejb.Stateless. Вы даже можете комментировать и использовать EJB непосредственно со страниц JSF - хотя я не уверен, что этот проект желателен. Чтобы ссылаться (вводить) любые компоненты, аннотированные с помощью @javax.ejb. *, Например. @Stateless, выберите @Inject над @EJB как описано здесь. (Возможно, предок этого ответа...)

Наконец, очень красивый обзор аннотаций Java EE 6 можно найти здесь: http://www.physics.usyd.edu.au/~rennie/javaEEReferenceSheet.html

Примечание: приведенная выше информация не от эксперта, а просто моего собственного взгляда с точки зрения новичков на эту <сильную > смехотворно запутывающую Java EE 6 аннотации спагетти. Более глубокое понимание еще предстоит разработать. Надеюсь, что этот ответ может быть общим, практическим ответом на эту путаницу - хотя в контексте первоначального вопроса он немного зашел в тупик.

Ответ 4

Как я просто прочитал в Weld Reference (стр. 12), @ManagedBean теперь суперплотный:

Вы можете явно объявить управляемый bean путем аннотации класса [email protected], но в CDI вы не нужно. Согласно спецификация, контейнер CDI рассматривает любой класс, который удовлетворяет следующие условия как управляемые bean:

  • Это не нестатический внутренний класс. Это конкретный класс, или аннотированный @Decorator.
  • Он не аннотируется с помощью аннотации, определяющей компонент EJB, или объявлен как класс EJB bean в EJB-jar.xml.
  • Он не реализует javax.enterprise.inject.spi.Extension.
  • Он имеет соответствующий конструктор: либо
  • класс имеет конструктор без параметров или
  • класс объявляет конструктор аннотированный @Inject.