当我学习JSF2时，我意识到我不确定支持组件应该是什么。从设计的角度来看，EJB 和 ？@ManagedBeans
最后，我将使用 JPA，因此 EJB 是业务层的自然选择。直接从 JSF 使用 EJB 是一种好的做法吗（如此处所述）？
目前，我倾向于使用不需要访问业务层（例如视图助手）或处理请求/会话数据的组件。对于其他目的，例如在网格中列出某些内容，我将直接访问EJB。@ManagedBeans
这是一个好的设计吗？为了干净的层分离，我应该对所有支持Bean使用，即使在某些情况下它们只委托给EJB？@ManagedBeans
非常有效的问题，但我想答案取决于项目方法的“严格性”。JSF 支持 Bean 和 EJB 之间确实存在一些冗余，因为两者都实现了一些业务逻辑。
在 JSF 功能的理想用法中，支持 Bean 确实是干净的业务逻辑代码。但在实践中，一些与表示相关的逻辑经常在其中泄漏。convertersrenderedvalidator
理想情况下，此与表示相关的逻辑不应位于 EJB 中。此与表示相关的逻辑可能取决于人脸包，但不是必需的。正是它所做的使它与演示相关与否。
但是，统一的组件模型具有一些优点。这是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、Servlets、独立 Java SE 远程客户机或其他任何位置很好地使用。
即使所有的豆子都会变成CDI豆子，那么这并不能改变这种基本的责任分工。
