为什么实体 bean 不应该由 JSF 框架管理？答案

【问题标题】：why shouldn't entity bean be managed by JSF framework?为什么实体 bean 不应该由 JSF 框架管理？
【发布时间】：2014-08-21 16:28:12
【问题描述】：

我读了一些帖子（特别是 BalusC 帖子）并搜索了原因（不是很深），但我找不到为什么不应该使用实体 bean 作为托管 bean。什么原因？（我正在学习“Pro JSF 和 HTML5”，在本书中，实体 bean 被用作托管 bean。）

【问题讨论】：

标签： jsf managed-bean entity-bean

【解决方案1】：

关注点分离。

通常，企业应用程序是作为 EAR 而不是 WAR 开发和部署的。典型的 EAR 项目由作为“后端”的 EJB 子项目和作为“前端”的 WAR 子项目组成。 EJB 子项目包含所有 JPA 实体和 EJB 服务。 WAR 子项目包含所有 JSF 托管的 bean 和视图（以及与 JSF 不密切相关的内容，例如转换器、验证器、阶段侦听器等）。

一个好的 EJB 子项目可能没有对 JSF 有任何依赖。这使其可重用于不同的前端，例如 Spring MVC、JAX-RS、Struts2、纯 JSP/Servlet 甚至面向桌面的 Swing 应用程序。这也意味着没有一个您的 JPA 实体和 EJB 服务应该在类中有任何 javax.faces.* 导入/依赖。例如，在 JPA 实体或 EJB 服务中拥有 FacesContext 令人担忧，因为它不一定存在于其他前端。

“Pro JSF 和 HTML5”专注于简单的 WAR 项目。为了展示可能性和/或保持示例“简单”，这是“可以的”，但是一旦他们成长为开发企业应用程序，这实际上会误导初学者，如果这本书没有涵盖设计问题，则更是如此详细。

另见：

JSF Service Layer
Packaging EJB in JavaEE 6 WAR vs EAR - 我的同事 Arjan 的相关回答。

【讨论】：

谢谢。这是一个完美的答案。你能推荐一本好书吗？（我是初学者，想成为 JavaEE 和 JSF 方面的专家）你能告诉我选择什么 Web 服务器，GlassFish 还是 TomEE 或其他什么？
不客气。至于书，你手头的那本很好。然后是“在 GlassFish 中开始 Java EE 7”。至于服务器，我个人会推荐 WildFly。 TomEE 也可以。但绝对不是 GlassFish（不再）。自从 Oracle stopped 对其提供商业支持后，它不再被积极维护。值得一提的是，我目前正在为我的博客写一篇关于 WildFly 的 JSF 2.2 教程。可能会在一段时间内出现。
谢谢，帮了大忙。