Являются ли @ManagedBeans устаревшими в JavaEE6 из-за @Named в CDI / Weld?
Здесь много правильных ответов, но я хотел добавить это (для полноты):
Если вы в нижней части файла cpp реализации выполняете явное инстанцирование всех типов, которые будут использоваться шаблоном с, компоновщик сможет найти их как обычно.
Изменить: добавление примера явного создания экземпляра шаблона. Используется после того, как шаблон определен, и определены все функции-члены.
template class vector<int>;
Это создаст экземпляр (и, следовательно, сделает доступным для компоновщика) класс и все его функции-члены (только). Подобный синтаксис работает для функций шаблона, поэтому, если у вас есть перегрузки операторов, не являющихся членами, вам может понадобиться сделать то же самое для них.
Вышеприведенный пример бесполезен, поскольку вектор полностью определен в заголовках, за исключением случаев, когда common include file (precompiled header?) использует extern template class vector<int>, чтобы не создавать его из всех других (1000?) файлов, которые используют вектор.
3 ответа
Короче говоря, @ManagedBean имеет смысл для приложений, которые используют JSF, но не используют JSR 299 (по какой бы то ни было причине). Ниже более подробное объяснение от Гэвина Кинга:
Re: Сравнение с аннотациями @ManagedBean в JSF2? :
При просмотре примеров Weld и старых WebBeans документация, это выглядит как конкурент нового @ManagedBean JSF 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 сказано, что любой класс с соответствующим конструктором развернутый в "развертывании компонента" archive "является управляемым компонентом.
Учитывая, что EJB и CDI предоставляют возможно более удобные способы идентифицировать управляемый компонент, вы можете интересно, что такое
@ManagedBeanнеобходимо для.Ответ, как упоминалось Дэн, если у вас есть CDI доступны в вашей среде (для Например, если вы используете EE6), то@ManagedBeanпросто не совсем нужный.@ManagedBeanдействительно есть для использования людьми, использующими JSF2 без CDI .OTOH, если вы добавляете аннотацию к bean-компоненту
@ManagedBean, и у вас есть CDI в ваша среда, вы все еще можете использовать CDI, чтобы вводить что-то в ваш bean-компонент. Просто@ManagedBeanаннотация не требуется в этом кейс.Подводя итог, если у вас есть CDI доступный вам, он обеспечивает далеко превосходная модель программирования для
@ManagedBean/@ManagedPropertyмодель что JSF2 наследуется от JSF1 . Так на самом деле лучше, чем EE 6 Web профиль не требует поддержки@ManagedPropertyи т. Д. Идея заключается в что вместо этого вам следует просто использовать CDI.
Как я только что прочитал в Справочнике по сварке (стр. 12), @ManagedBean теперь лишний:
Вы можете явно объявить управляемый bean-компонент путем аннотирования класса bean-компонента @ManagedBean, но в CDI этого нет нужно. Согласно спецификация, контейнер CDI обрабатывает любой класс, удовлетворяющий следующие условия в качестве управляемого bean:
- Это не нестатический внутренний класс. Это конкретный класс или аннотированный @Decorator.
- Он не снабжен аннотацией, определяющей компонент EJB, или объявлен как класс EJB-компонента в ejb-jar.xml.
- Он не реализует javax.enterprise.inject.spi.Extension.
- У него есть соответствующий конструктор - либо:
- класс имеет конструктор без параметров, либо
- класс объявляет конструктор с аннотацией @Inject.
У вас есть выбор. Либо используйте @ManagedBean из JSF2 для связывания компонентов с формами, либо используйте аннотацию @Named из CDI. Если вы планируете делать только JSF, вы можете придерживаться @ManagedBean, но если вы хотите интегрироваться с EJB или использовать @ConversationScoped CDI, то идите по пути CDI.
Лично я считаю, что следующая версия JSF должна отказаться от @ManagedBean и стандартизировать CDI. Двойственность сбивает с толку новичков.