问支持Bean (@ManagedBean)还是CDI Bean (@Named)？

EN

CDI比普通的JSF更受欢迎，因为CDI允许JavaEE范围的依赖注入。您还可以注入POJO并对其进行管理。对于JSF，您只能注入CDI所能注入的一个子集。

使用CDI。

根据JSF2.3，@ManagedBean是不推荐使用的。另请参见spec issue 1417。这意味着没有理由选择@ManagedBean而不是@Named。这首先是在Mojarra 2.3.0测试版m06中实现的。

​

​

历史

核心区别在于，@ManagedBean是由JSF框架管理的，并且只能通过@ManagedProperty提供给另一个JSF托管bean。@Named由应用服务器(容器)通过CDI框架管理，并且通过@Inject可用于任何类型的容器管理工件，如@WebListener、@WebFilter、@WebServlet、@Path、@Stateless等，甚至是JSF @ManagedBean。从另一方面来看，@ManagedProperty 不会在@Named或任何其他容器管理的工件中工作。它只在@ManagedBean内部有效。

另一个不同之处在于，CDI实际上是在每个请求/线程的基础上注入委托给目标作用域中的当前实例的代理(就像EJB是如何注入的一样)。这种机制允许在较宽范围的bean中注入较窄范围的bean，这在JSF中是不可能的。在这里，JSF通过调用setter直接“注入”物理实例(这也是为什么需要setter，而不是@Inject需要的原因)。

虽然不是直接的缺点-还有其他方式- @ManagedBean的范围只是有限的。从另一个角度来看，如果你不想为@Inject暴露“太多”，你也可以只保留你的托管bean @ManagedBean。这就像protected和public的对决。但这并不真正算数。

至少，在JSF2.0/2.1中，通过CDI管理JSF backing的主要缺点是没有与@ViewScoped对等的CDI。@ConversationScoped很接近，但仍然需要手动启动和停止，并且它将一个丑陋的cid请求参数附加到结果URL。JSF通过完全透明地桥接MyFaces的javax.faces.bean.ViewScoped到CDI来简化这一过程，因此您可以只执行@Named @ViewScoped，但是它将一个丑陋的windowId请求参数附加到结果URL，这也适用于普通的页面到页面导航。OmniFaces使用真正的CDI解决了所有这些问题，它真正将bean的作用域绑定到@ViewScoped视图状态，而不是任意的请求参数。

JSF2.2(在这个问题/答案之后3年发布)在javax.faces.view.ViewScoped风格中提供了一个新的完全兼容CDI的@ViewScoped注释。JSF2.2甚至还附带了一个只有CDI的@FlowScoped，它没有@ManagedBean等效项，因此将JSF用户推向了CDI。如果您目前仍在使用@ManagedBean，强烈建议您切换到@ManagedBean，为将来的升级做好准备。在兼容Java EE Web Profile的容器中，例如WildFly、TomEE和GlassFish，可以很容易地使用CDI。对于Tomcat，您必须单独安装它，就像您已经对JSF所做的那样。另请参阅How to install CDI in Tomcat?

对于Java EE 6和CDI，您可以使用不同的受管Bean选项

• @javax.faces.bean.ManagedBean参考JSR314，并在JSF2.0中引入。主要目标是避免将faces-config.xml文件中的配置配置为使用JSF Page中的bean。
• @javax.annotation.ManagedBean(“myBean”)是由JSR316定义的。它概括了在Java中其他地方使用的JSF托管bean几乎与上面的相同，只是您需要在EE
• @javax.inject.Named(“myBean”) /WEB-INF文件夹中使用一个beans.xml文件来激活CDI。