非常有效的问题，但我想答案取决于您的项目方法的“严格性”。JSF 支持 bean 和 EJB 之间确实存在一些冗余，因为它们都实现了一些业务逻辑。
在 , , 等的 JSF 特性的理想使用中，支持 bean确实可以是干净的业务逻辑代码。但在实践中，一些与表示相关的逻辑经常在其中泄漏。convertersrenderedvalidator
理想情况下，这种与表示相关的逻辑不应该在 EJB 中。这种表示相关的逻辑可能依赖于 faces 包，但不是必需的。它的作用决定了它是否与演示相关。
不过，统一的组件模型有一些优点。这是Seam和Spring采用的方法。在这两种情况下，具有声明式事务等的业务组件都可以直接在 JSF 中使用（Spring 不使用 EJB，但提供了类似的模型）。然而，EJB 纯粹主义者会说您应该将两者分开。
所以对我来说，这最终是一个项目的品味和规模的问题。我可以想象，对于在 JSF 中使用 EJB 的中小型项目来说效果很好。对于这种严格性至关重要的大型项目，请确保不要拧紧层。
在 Java EE 6 中，各种托管 bean 之间存在一些重叠：JSF 托管 bean (@ManagedBean)、CDI 托管 bean (@Named) 和 EJB bean (@Stateless、@Statefull、@Singleton)。
在视图层中，我没有看到坚持使用@ManagedBean 的任何特殊优势。CDI 变体@Named 似乎能够做同样的事情甚至更多，例如为您提供对转换范围的访问。
目前的想法似乎是最终 EJB 组件模型也将被改造为一组 CDI 注释。尤其是专家组成员 Reza Rahman 经常暗示这一点。参见Java EE 6 中的依赖注入 - 第 1 部分
目前这还没有发生，所以 EJB bean 仍然是最容易放置业务逻辑的地方，尤其是当 JPA 用于持久性时。
尽管如此，无论 CDI 是否会获得 EJB 的功能，恕我直言，为“支持 bean”概念使用单独的 bean 并为“业务逻辑”使用单独的 bean 仍然是最佳实践。
支持 bean 可以非常苗条，只包含一些对模型对象和服务 (EJB) 的引用。支持 bean 的操作方法几乎可以直接委托给服务，但它们的附加价值在于为用户提供反馈（在成功或失败时添加 FacesMessages）和进行小的 UI 修改（例如，将布尔值设置为 false 以显示一些对话框） .
服务（业务逻辑）不应该对任何特定的表示一无所知。它们应该同样适用于 JSF 支持 bean、JAX-RS、Servlet、独立的 Java SE 远程客户端或其他任何东西。
即使所有 bean 都将成为 CDI bean，那么这也不会改变这种基本的职责分工。
有趣的文章，不知道。然而，对我来说，这篇文章更像是对 JSF 托管 bean 的咆哮。它还将 EJB 与 JSF 紧密耦合在一起。它在小型（个人）应用程序中可能很有趣，但在您希望完全控制所服务的 EJB 的现实世界 SOA 应用程序中可能不有趣。
至于哪一个用于什么，我只想@ManagedBean表示一个 JSF 模型——它与一个或多个特定的 JSF 视图相关联。您可以完美地将@EJBs 用于非 JSF 特定的业务逻辑和/或数据模型。您可以在 JSF 模型中注入@EJBs 并将其委托给 action 方法，也可能是 getter/setter，但您不应该反过来，即不要在 an 中定义 JSF 模型@EJB，这会导致紧密耦合并且会使@EJBs在 JSF 上下文之外无法使用。就目前而言，您的设计听起来不错，只要您注意不要从类javax.faces中的包中导入任何内容@EJB。
通过从您的 XHTML 调用 EJB，您在视图和业务层中的实现选择之间引入了紧密耦合。
如果您使用托管 bean 来调用 EJB，[或者甚至放入业务委托]，您将能够将业务层完全更改为 Spring，而不会影响视图层 (XHTML)。
这在技术上是可行的，并且很容易让您（JSR 299）能够将 EJB 用作您的托管 bean，这可能是这些供应商希望您做的 - 专注于细节。但这是否是正确的做法？- 不。