JSF2-支持EJB还是ManagedBean?

在一个 理想的 converters , rendered , validator 等等。背豆 能够

做

但是,统一的组件模型有一些优点。这是我们采取的方法 Seam Spring . 在这两种情况下,具有声明性事务等的业务组件都可以直接在JSF中使用(Spring不使用EJB,但提供了类似的模型)。然而,EJB纯粹主义者会说您应该将两者分离开来。

所以对我来说,这最终是一个品味和项目规模的问题。我可以想象,对于一个在JSF中使用EJB的中小型项目来说,它可以很好地工作。对于更大的项目,这种严格性是至关重要的,确保你不螺丝的层。

在视图层中,我看不出坚持使用@ManagedBean有什么特别的好处。CDI variant@Named似乎可以做同样的事情,而且还可以做更多的事情,例如,为您提供对转换范围的访问。

Dependency Injection in Java EE 6 - Part 1

尽管如此,无论CDI是否获得EJB的功能,最好的做法仍然是为“backingbean”概念使用一个单独的bean,为“businesslogic”使用一个单独的bean。

backingbean可以非常瘦,只包含一些对模型对象和服务(ejb)的引用。backingbean的操作方法几乎可以直接委托给服务,但它们的附加值是向用户提供反馈(在成功或失败时添加faces消息)和进行小的UI修改(例如,将布尔值设置为false以显示一些对话框)。

即使所有bean都将成为cdibean,那么这并不会改变这种基本的责任划分。

有趣的文章,我不知道。然而,对我来说,这篇文章闻起来更像是对JSF管理bean的咆哮。它还将EJB与JSF紧密耦合。在小型(个人)应用程序中,这可能很有趣,但在实际的SOA应用程序中,您可能不希望完全控制EJB的服务。

@ManagedBean 表示一个JSF模型——它与一个或多个特定的JSF视图相关联。你完全可以用 @EJB 对于非JSF特定的业务逻辑和/或数据模型。你可以注射 @EJB @EJB ,这会导致紧密耦合,并会 在JSF上下文之外是不可用的。到目前为止,你的设计听起来不错,只要你看不进口任何东西 javax.faces 包装在 @EJB

在技术上是可能的,而且对您来说(JSR299)能够使用EJB作为托管bean非常容易,这可能就是这些供应商希望您做的事情—专注于细节。但这样做是否正确号码