我正在阅读this post，这让我有些困惑：在该帖子中提到了与每个特定容器使用的注释：JSF，CDI或EJB容器。
作为一名初学者，我学习了JSF框架并习惯了它的@ManagedBean注释及其可选的name参数，用于从JSF页面引用bean，并且对CDI知之甚少，而我正在使用EJB作为其强大的功能（甚至在阅读这篇文章之后，我仍然认为EJB比CDI更强大，功能更强。）
所以.. JSF和CDI容器都有自己的注释和在网页上引用bean的方法，但EJB只有@Stateless（或@Stateful），因此无法在网页上引用，这意味着JSF容器必须始终附加EJB（因为我认为混合EJB和CDI容器是荒谬的，因为它们几乎相似但是为了这一点，我希望有人告诉我，如果我错了）。
JSF容器的问题在于它是
“仍然没有完整和成熟的容器”
正如那篇帖子所说的那样，我知道的最糟糕的事情是在@ManagedBean旁边的Netbeans中发出警告信息：
“javax.faces.bean包中的注释将被删除 下一个JSF版本。建议使用CDI。“
（好吧，这里有另一个注释的替代包：javax.annotation.ManagedBean，但我不知道我是否可以使用它，也不知道它是否有一个参数用于在网页上引用bean以及哪一个它是）
所以现在我开始怀疑未来还应该使用哪种容器组合。 CDI + EJB是未来吗？
为所有人欢呼。
答案 0 :(得分：10)
Java EE 7正在变得更加CDI对齐。因此，EJB将只是CDI +强大服务（异步，消息使用者，计划任务......）的一个非常特殊的案例。考虑到这一点，@ManagedBean变得多余，因为@Named允许您将bean公开给JSF页面。
随着技术的成熟，您将以CDI容器无处不在结束（即使对于独立应用程序）。
要记住一些要点：
@Stateless或@Stateful。现在，每个类都可以@Named并注入（并使用这意味着拦截，生命周期管理，资源注入的服务）。@ManagedBean。每个@Named都可能位于具有相关范围（会话，视图...）@Named的{{1}}（Java EE 7）都可以写入数据库。架构得到简化，模式相同（MVC，Boundary-Control-Entity），只需更改注释和一点点实现。
目前有一个名为Apache DeltaSpike的成熟项目，其中一些相关的CDI扩展是可移植的，在大多数情况下会简化您的生活（即使您使用的是Java EE 6！）。
注意：在Java EE 7而不是Java EE 6中使用完整的CDI会更容易，因为6没有 @Transactional，所以你需要自己创建一个事务拦截器。
非EJB bean的事务支持：Transactional Interceptor 在DeltaSpike中为Java EE 7中的@Transactional铺平了道路。
答案 1 :(得分：2)
首先，我想区分EJB和JSF Managed Beans。 EJB是持久对象，作为一般规则，您不能将它们直接用作JSF托管对象，因为JSF对象管理子系统不允许数据库的需求。最重要的是，使用不同的密钥交换和输出对象的实例。所有数据库操作都需要应用程序代码，因为JSF无法帮助您。它不是为此而设计的。
对于传统管理与 CDI：除非Oracle使用“Microsoft”并放弃对已弃用项目的传统长期支持，否则使用旧式ManagedBean注释应该更安全。事实上，根据您所定位的Enterprise Java容器的版本，CDI可能尚未正常运行。
如果您确定您将始终获得CDI支持，那么编写CDI可能会更好，因为它是指定用于长期支持的CDI。