在 JSF 和 JPA 项目中使用 POJO 作为模型，对吗？

Posted 2023-04-18

【中文标题】在 JSF 和 JPA 项目中使用 POJO 作为模型，对吗？

【英文标题】：Using POJO as Model in JSF and JPA project, is that right?

【发布时间】：2011-11-10 06:30:58

【问题描述】：

我正在使用 JSF 2 和 JPA 2 (EclipseLink 2.3) 开发一个项目。 在 JSF 2 中，我了解到我们必须将模型与控制器分开，并将相同的东西与视图分开（感谢 BalusC）。 但是现在有了从JPA生成的POJO，我想知道bean，模型，现在应该是pojo。

我的视图将是我的 .xhtml 页面，在 JSF 2.0 中开发，它将与我的控制器交互，然后在控制器中调用 DAO 的类，然后在我的数据库中操作。

这是对的吗？我的意思是在 MVC 的概念中？ 我想把所有事情都做对，有什么建议吗？

提前致谢。

【问题讨论】：

嗨瓦尔特。当您说“我想知道 bean，模型，现在应该是 pojos。”时，您是什么意思？从我看到 JSF 的方式来看，页面与可以调用服务类的 bean 交互，然后与 DAO 类交互。域对象可以直接在 bean 中进行操作，也可以成为更复杂模型的一部分以适应视图。

嗨，James，我的意思是，如果 POJO 应该像 ManageBeans 之前只使用 jsf 那样工作。

我不熟悉 ManageBeans。我会说 POJO/实体可以用作 MVC 意义上的模型的基础。

【参考方案1】：

“MVC”在 JSF 中有多种观点。从高级视图来看，模型由 EJB/JPA 和最终的 DAO/DTO（如果有的话）表示。视图由您自己的 JSF 代码（由托管 bean 和 Facelets 模板组成）表示。控制器由FacesServlet 表示。

从低级视图（高级视图的进一步细分）来看，模型由实体或 DTO 表示。视图由您的 Facelets 模板表示。控制器由您的托管 bean 表示。它基本上是一个 M(MVC)C。

请注意，“POJO”是旧 J2EE/Hibernate 时代的一个相当遗留的术语。如今，在 Java EE/JPA 中，它们被称为“实体”。是的，就是那些@Entity Javabeans。另请注意，有些人可能会选择使用普通的 DTO，而不是应该将 JSF 代码与服务层分离的实体。然后，JSF 应该使用这些 DTO 作为模型，而服务层应该反过来在这些 DTO 和真实实体之间进行映射。这在我看来是没有必要的。 EJB3/JPA2 是一个非常漂亮的 API，它已经最大限度地减少了许多样板代码，您可以像在旧 J2EE 时代那样使用 DAO/DTO 来实现这些样板代码。对于 Java EE 6 及更高版本，实际上不需要将服务层切换到例如 Spring。一切都已经经过深思熟虑和标准化。

另见：

What components are MVC in JSF MVC framework? Difference between DTO, VO, POJO, JavaBeans? I found JPA, or alike, don't encourage DAO pattern

【讨论】：

一般来说，我会坚持使用纯 Java EE 6 API 并保持代码尽可能简单，而不需要太多层和映射/复制。这对其他人来说可能听起来有点争议，但是为什么您将来会选择 Java EE 6 标准已经提供的东西之外的东西呢？在过去，这是不同的。没有单一的标准。所有第 3 方框架都有自己的处理方式。然后通过一些额外的层将其抽象出来。

"控制器由 FacesServlet 表示。"很高兴你能清楚地说明这一点（它证实了我的一些想法）。关于 MVC 意义上的模型，您是否知道任何具有包含实体/DTO 的视图特定模型的应用程序？我的意思是，除了从实体中提取信息之外，可能还需要从实体中制作更复杂的内容或添加仅在视图中使用的数据（例如某种控制面板 GUI 中的组件状态）。

@BalusC，感谢您的解释（我想称您为“教授”，因为您（和堆栈）教会了我很多关于良好实践、正确概念编码的知识（我已经看到了之前的代码很乱）），谢谢'教授'，祝你星期天愉快=]

【参考方案2】：

不完全正确。通常最好避免在视图中直接引用模型对象；您可以将它们替换为仅用于包含要显示的数据的 DTO（数据传输对象）

【讨论】：

DTO 是如何构建的？我对此感到好奇，因为我看到一些架构提到了 DTO。我想他们的作用是限制对域模型的依赖。

它们只是带有 getter 和 setter 的 bean，但它们根本没有实现任何逻辑。在这种情况下，它们将在模型使用 dao 从 db 读取数据后由模型（通常的企业应用程序中的服务）构建和填充

@Simone，但是使用 DTO，我会复制我的代码吗？我的意思是，我创建了一个 ManageBean 来引用一个实体，对吗？

在您的情况下，managebean 将是 DTO；有一些重复的逻辑，但用于解耦应用程序的各个层

@James 这没有错，但我更希望 DAO 返回实际的模型对象，例如直接与 ORM 一起使用的模型对象。我更希望 DTO 从服务返回到控制器，然后返回到视图。但这并没有错，因为实际上可以通过不同的层使用各种不同的DTO，这只是一种模式

【参考方案3】：

嗯，在我看来，这是不正确的。 XHTML 页面是视图，但控制器是 JSF servlet（已经由框架提供），而您所谓的“控制器”实际上是模型（业务逻辑）。 JPA POJOS 是模型（数据模型）的一部分。

从视图中，您应该调用业务逻辑来获取结​​果（作为 JPA Pojos）并在视图中直接使用它们（不需要在您的架构中转换为 DTO）。

在您的模型中，您可以随心所欲地组织业务逻辑（如果您认为需要一个 DAO 层，在行业中很常见，您可以直接放入）。

【讨论】：

嗨 edutesoy，我认为 BalusC 和 Bozho ***.com/questions/2100115/… 的观点是正确的，当你使用 MVC 时更容易抽象你的逻辑，你只需要担心 DAO。