在学习 JSF2 时，我意识到我不确定支持组件应该是什么。从设计的角度来看，EJB 和@ManagedBeans 有什么区别？
最后我要使用JPA，所以EJB是业务层的自然选择。直接从 JSF 使用 EJB 是一种好习惯（如 here 所述）吗？
目前我倾向于将@ManagedBeans 用于不需要访问业务层（例如视图助手）或处理请求/会话数据的组件。用于其他目的，例如在网格中列出一些东西，我会直接访问 EJB。
这是一个好的设计吗？为了干净的层分离，我是否应该对所有支持 bean 使用@ManagedBeans，即使在某些情况下它们只委托给 EJB？
【问题讨论】：
通过从 XHTML 调用 EJB，您在视图和业务层的实现选择之间引入了紧密耦合。
如果您使用托管 bean 来调用 EJB，[或者甚至放入业务委托]，您将能够将您的业务层完全更改为 Spring，而不会影响视图层 (XHTML)。
这在技术上是可行的，并且很容易让您（JSR 299）能够使用 EJB 作为您的托管 bean，而这可能是这些供应商希望您做的 - 专注于细节。但这是否是正确的做法？ - 没有。
【讨论】：
在 Java EE 6 中，各种托管 bean 之间存在一些重叠：JSF 托管 bean (@ManagedBean)、CDI 托管 bean (@Named) 和 EJB bean（@Stateless、@Statefull、@Singleton）。
在视图层中，我看不出坚持使用@ManagedBean 有什么特别的优势。 CDI 变体 @Named 似乎能够做同样的事情，甚至更多，例如为您提供转换范围的访问权限。
目前的想法似乎是最终 EJB 组件模型也将被改造为一组 CDI 注释。尤其是专家组成员 Reza Rahman 经常暗示这一点。参见例如Dependency Injection in Java EE 6 - Part 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 功能使用中，converters、rendered、validator 等。支持 bean可以确实是干净的业务逻辑代码。但在实践中，一些与表示相关的逻辑经常在其中泄漏。
这个与表示相关的逻辑理想情况下不应该在 EJB 中。这种表示相关的逻辑可能依赖于 faces 包，但不是必需的。正是它所做的 决定了它是否与演示相关。
不过，统一的组件模型有一些优势。这是Seam 和Spring 采用的方法。在这两种情况下，具有声明式事务等的业务组件都可以直接在 JSF 中使用（Spring 不使用 EJB，但提供了类似的模型）。然而，EJB 纯粹主义者会说您应该将两者分开。
所以对我来说，这最终是一个项目的品味和规模的问题。我可以想象，对于在 JSF 中使用 EJB 的中小型项目来说效果很好。对于这种严格性至关重要的大型项目，请确保不要拧紧层。
【讨论】：
@ManagedBean，这需要稍作修改以使 bean 成为 @Named 并更改范围。 EJB 提供了一些很棒的功能，您想成为多“纯粹”的人取决于您。我一般不介意在我的页面上使用 EJB。
有趣的文章，不知道。然而，对我来说，这篇文章更像是对 JSF 托管 bean 的咆哮。它还将 EJB 与 JSF 紧密耦合在一起。这在小型（个人）应用程序中可能很有趣，但在您希望完全控制所服务的 EJB 的现实世界 SOA 应用程序中可能并不有趣。
至于哪一个用于什么，我会坚持使用@ManagedBean 来表示一个JSF 模型——它与一个或多个特定的JSF 视图相关联。对于非 JSF 特定的业务逻辑和/或数据模型，您可以完美地使用 @EJBs。您可以在 JSF 模型中注入 @EJBs 并将其委托给操作方法，也许还有 getter/setter，但您不应该反过来，即不要在 @EJB 中定义 JSF 模型，这会导致紧密耦合并且会使@EJBs 在 JSF 上下文之外无法使用。就目前而言，您的设计听起来不错，只要您注意不要从 @EJB 类中的 javax.faces 包中导入任何内容。
【讨论】：