为什么我不能在Java EE 5中将会话bean作为JSF支持bean

Question

AFAIK，JBoss Seam的全部目的是集成EJB和JSF。

Seam in Action一书中写道：

  

按照设计，EJB组件不能直接绑定到JSF视图。 EJB很棒   组件是可伸缩的，事务性的，线程安全的和安全的，但它没有做太多   如果它们与Web层完全隔离，只能通过JSF访问，那就太好了   支持豆作为中间人。

但是我找不到这种不可能性的原因/动机，为什么它们与网络层隔离？为什么我不能将EJB用作辅助bean？关心赐教？

Answer 1

  

但是我找不到这种不可能性的原因/动机，为什么他们与网络层隔离？

传统上这样做是为了强制实现业务逻辑和视图相关代码之间的分离。混合这些是大多数初学者所做的，它总是会导致从长远来看难以维护的系统。

通过允许EJB直接用作支持bean，人们将把FacesMessages放在其中，并将格式化特定于一个特定页面，并呈现代码等。

严格隔离可以防止出现这些错误。然而，这也为那些初学者开始使用EJB提供了标准，并且给了EJB一点点困难的声誉（尽管使用EJB3并不是这样）。在最新的Java EE 6版本中，通过允许在Web模块中没有接口的情况下定义EJB，可以实现大量的混合。使用CDI注释，它们可直接用作支持bean。

根据您的观点，这是向前迈出的一步（更简单，更少的约束，更少的必需工件），但它也可以被视为向后退一步（再次促进视图和业务逻辑的混合，在JSP上弃用scriptlet的东西试图阻止）。

Answer 2

Seam的目的不是为了做到这一点。然而，CDI（Weld）是。使用CDI，您可以@Inject JSF bean中的EJB。 （正如arjan所说 - 你可以在没有CDI的情况下做到这一点，因为CDI是JavaEE6，你可以尝试使用@EJB private RemoteInterface bean）

但这与JPA实体无关。尽管JPA被认为是EJB的一部分，并且它的前身是“实体bean”，一种特殊类型的EJB，但最好不要将EJB和JPA视为一种思考。 JPA是ORM标准。 EJB是一种服务/组件模型。

@Entity个对象由EntityManager管理。它们不是由ejb容器管理，也不是由煤层管理，也不是由CDI管理。这是因为它们不适合这三种应用的组件模型。实体通常由开发人员实例化。使用CDI / EJB / Seam，它是实例化组件，管理组件并执行注入的框架。