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

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

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

Ответы [ 4 ]

51 голосов
/ 17 июня 2010

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

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

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

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

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

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

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

  • Спецификация EJB говорит, что класс подчиняется определенному программированию ограничения с @Stateless или @Stateful аннотация, развернутая в EJB jar - это управляемый боб.

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

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

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

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

15 голосов
/ 29 мая 2010

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

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

10 голосов
/ 20 октября 2011

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

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

Таким образом, @ManagedBean не может быть полностью заменен CDI, опять же, если вы используете @ViewScoped bean - по крайней мере, без расширения CDI или с использованием модуля Seam 3 Faces .Использование bean-объектов в области видимости почти всегда происходит при использовании наборов 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 .Если вы получаете странное поведение от ваших bean-компонентов (или bean-компонентов, которые, похоже, ничего не делают), причиной может быть неправильное сочетание аннотаций.

Возможно смешивание 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ссылки с ваших страниц JSF AFAIK.До сих пор у меня не было проблем с вышеуказанными комбинациями, поэтому вы можете считать @ManagedBean устаревшим здесь.

Остался сервисный уровень, здесь в основном транзакционные EJB-сервисные бины, объявленные как

@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 spaghetti .Больше понимания еще предстоит разработать.Я надеюсь, что этот ответ может быть общим, практическим ответом на эту путаницу - даже если он немного зашел в контексте исходного вопроса.

7 голосов
/ 28 мая 2010

Как я только что прочитал в Справке по сварке (стр. 12), @ManagedBean теперь излишен:

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

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