问题描述
由于 CDI(及其实现 Weld),JEE6 中的每个 POJO 都可以使用 @Named
进行注释,这使得视图可以访问 POJO.
这是否意味着 ManagedBeans 现在完全过时了?还是我错过了 @ManagedBean
仍然有意义的东西?
简而言之,@ManagedBean
对于使用 JSF 但不使用 JSR 299(无论是什么原因)的应用程序是有意义的.下面是 Gavin King 的详细解释:
Re:与 JSF2 中的 @ManagedBean 注释的比较?:
在查看 Weld 示例和较旧的 WebBeans 时文档,它看起来像一个新@ManagedBean JSF 的竞争对手2.0 注释.是否有关于我们何时想要使用的任何信息一个?
这是个好问题,我不是真的完全同意到目前为止已发布的答案.
新的 EE Managed Beans 规范定义一个基本组件模型Java EE,以及一个非常基础的一组容器服务(@Resource
,@PostConstruct
, @PreDestroy
).
这个想法是其他规格(从 EJB、CDI、JSF 和新的 Java 拦截器规范)建立在这个基础组件模型和层附加服务,例如事务管理,类型安全依赖注入,拦截器.所以在这个级别,托管 bean,CDI,拦截器和 EJB 规范所有工作都齐头并进,并且高度重视互补.
现在,托管 Bean 规范是相当开放的准确识别哪些类是托管豆.它确实提供了@ManagedBean
注解为一机制,但它也允许其他定义不同的规范机制.因此,例如:
EJB 规范说一个类遵守某些编程
@Stateless
或@Stateful
注释部署在一个EJB jar 是一个托管 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.
Because of CDI (and its implementation Weld), every POJO in JEE6 can be annotated with @Named
, which makes the POJO accessible to the view.
Does that mean that ManagedBeans are completely obsolete now?Or did I miss something where @ManagedBean
still makes sense?
In short, @ManagedBean
makes sense for applications that use JSF but do not use JSR 299 (whatever the reason is). Below a longer explanation from Gavin King:
It's a good question, and I'm not really in full agreement with the answers that have been posted so far.
The new EE Managed Beans specification defines a base component model for Java EE, together with a very basic set of container services (@Resource
, @PostConstruct
, @PreDestroy
).
The idea is that other specifications (beginning with EJB, CDI, JSF and the new Java Interceptors spec) build upon this base component model and layer additional services, for example transaction management, typesafe dependency injection, interceptors. So at this level, the managed beans, CDI, interceptors and EJB specifications all work hand-in-hand and are highly complementary.
Now, the Managed Beans specification is quite open-ended with respect to identifying exactly which classes are managed beans. It does provide the @ManagedBean
annotation as one mechanism, but it also allows other specifications to define different mechanisms. So, for example:
The EJB specification says that a class obeying certain programming restrictions with a
@Stateless
or@Stateful
annotation deployed in an EJB jar is a managed bean.The CDI specification says that any class with an appropriate constructor deployed in a "bean deployment archive" is a managed bean.
Given that EJB and CDI provide arguably more convenient ways to identify a managed bean, you might wonder precisely what @ManagedBean
is needed for. The answer, as alluded to by Dan, is that if you have CDI available in your environment (for example, if you are using EE6), then @ManagedBean
is just not really needed. @ManagedBean
is really there for use by people who are using JSF2 without CDI.
OTOH, if you do annotate a bean @ManagedBean
, and you do have CDI in your environment, you can still use CDI to inject stuff into your bean. It's just that the @ManagedBean
annotation is not required in this case.
To summarize, if you do have CDI available to you, it provides a far superior programming model to the @ManagedBean
/@ManagedProperty
model that JSF2 inherits from JSF1. So superior, in fact, that the EE 6 web profile does not require support for @ManagedProperty
etc. The idea being that you should just use CDI instead.
这篇关于由于 CDI/Weld 中的 @Named,@ManagedBeans 在 JavaEE6 中是否已过时?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!