当我学习JSF2时，我意识到我不确定支持组件应该是什么。从设计的角度来看，EJB与@ManagedBeans之间有什么区别？
最后我将使用JPA，因此EJB是业务层的自然选择。直接从JSF使用EJB是一个好习惯（如here所述）？
目前，我倾向于将@ManagedBeans用于不需要访问业务层的组件（例如视图助手）或处理请求/会话数据。出于其他目的，例如列出网格中的内容，我会直接访问EJB。
这是一个好设计吗？为了清除层分离，我应该为所有支持bean使用@ManagedBeans，即使在某些情况下它们只委托给EJB吗？
答案 0 :(得分：13)
非常有效的问题，但我想答案取决于项目方法的“严格性”。 JSF支持bean和EJB之间确实存在一些冗余，因为它们都实现了一些业务逻辑。
使用converters，rendered，validator等对JSF功能的理想用法，支持bean 确实是干净的业务逻辑代码。但在实践中，一些与表示相关的逻辑经常泄漏。
这种与表示相关的逻辑理想情况下不应该在EJB中。该表示相关逻辑可以取决于面包，但不是必需的。 做什么使它与演示相关或不相关。
统一组件模型虽然有一些优点。这是Seam和Spring采取的方法。在这两种情况下，具有声明性事务的业务组件等都可以直接在JSF中使用（Spring不使用EJB但提供类似的模型）。然而，EJB纯粹主义者会说你应该分离这两者。
所以对我而言，这最终是一个关于项目品味和规模的问题。我可以想象，对于在JSF中使用EJB的小型/中型项目工作正常。对于严格要求严格的大型项目，请确保不要拧紧图层。
答案 1 :(得分：8)
在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，这也不会改变这种基本的责任分工。
答案 2 :(得分：3)
有趣的文章，对此并不了解。但是，对我来说，这篇文章更像是对JSF托管bean的咆哮。它还将EJB与JSF紧密结合在一起。它可能在小型（个人）应用程序中很有意思，但在现实世界的SOA应用程序中，您可能无法完全控制已经提供服务的EJB。
至于哪一个用于什么，我只想坚持@ManagedBean来表示一个JSF模型 - 它与一个或多个特定的JSF视图相关联。您可以完美地将@EJB用于非JSF特定的业务逻辑和/或数据模型。您可以在JSF模型中注入@EJB并将其委托给操作方法，也可能是getter / setter，但是您不应该反过来，即不要在@EJB中定义JSF模型，这会导致紧密耦合，并且会使@EJB在JSF上下文之外无法使用。到目前为止，只要您注意不从javax.faces类@EJB包中导入任何内容，您的设计听起来就会很好。
答案 3 :(得分：2)
通过从XHTML调用EJB，您将在视图和业务层中实现选择之间引入紧密耦合。
如果使用托管bean来调用EJB，[甚至放入业务委托]，您将能够完全将业务层更改为Spring，而不会影响视图层（XHTML）。
技术上是否可行，并且您很容易（JSR 299）能够使用EJB作为托管bean，这可能是这些供应商希望您做的事情 - 专注于具体细节。但这是否是正确的事情呢？ - 不。