持久化对象是什么？

Question

我正在阅读Java EE教程，在这里看到以下句子：

实体是一种轻量级的持久化领域对象。

我搜索了持久化对象，但没有找到清晰的解释。

那么持久化领域对象具体是什么？

- Koray Tugay

---

相关链接：业务对象，在技术上也被称为领域对象和持久化领域对象。 - Luiggi Mendoza

轻量级意味着它可在 JEE（JPA）容器之外使用，这意味着您可以将其与任何 J2SE 应用程序（如tomcat，spring 或独立的 Java 应用程序等）一起使用。这是因为底层实现通常由独立的 ORM 框架（如 hibernate）提供。在这种情况下，您将使用“应用程序管理的 EntityManager”，并且将无法利用事务上下文传播。（除非使用 Spring 充当 JEE 容器的角色） - Gab

Answer 1

Java EE假设有一个称为领域模型的东西。领域模型由表示实体的对象组成，其中实体是具有与业务相关的标识的事物。(例如，如果您在银行工作，您的领域可能涉及帐户、客户、持股和贷款等事物)。

这里是Bauer和King的Java Persistence with Hibernate中描述领域模型的一句话引用:

3.1.1. 分析业务领域

在软件开发过程中，如果没有现成的遗留代码或遗留数据库，就需要从分析问题领域开始。

在这个阶段，您需要与问题领域专家一起确定与软件系统相关的主要实体。实体通常是系统用户理解的概念：支付、客户、订单、商品、出价等等。有些实体可能是用户所思考的较为抽象的事物的抽象，比如价格算法，但即使这些实体通常也能为用户所理解。所有这些实体都在业务的概念视图中找到，我们有时称之为业务模型。面向对象软件的开发人员和架构师分析业务模型并创建一个面向对象模型，仍然处于概念层面（没有 Java 代码）。这个模型可能只是存在于开发人员的头脑中的简单的心理形象，也可能像 ArgoUML 或 TogetherJ 这样的计算机辅助软件工程（CASE）工具创建的 UML 类图一样复杂。在图 3.1 中显示了一个简单的 UML 模型。

这个模型包含了在任何典型的拍卖系统中都会找到的实体：类别、商品和用户。这些实体及其关系（以及可能的属性）都由这个问题领域的面向对象模型表示。我们称这种仅包含用户感兴趣的实体的面向对象模型为领域模型。它是真实世界的一个抽象视图。

分析和设计领域模型的动机是为了捕捉业务信息的本质，以便实现应用程序的目的。

理想情况下（在一种称为领域驱动设计的方法中），这些领域对象具有两个特征：它们不知道基础设施问题，如持久性或事务，并且它们包含实现状态转换的逻辑，当它们在业务处理过程中被操作时；这两者的组合意味着业务逻辑可以与基础架构分开测试。在现实世界中，更典型的是看到贫血领域对象，它们不包含任何业务逻辑，所有业务逻辑都在事务脚本中结束。

无论如何，思路是您拥有由持久实体组成的领域模型。有某种配置（注释或XML文件或其他）将实体及其属性映射到数据库中的表和列，并将实体之间的关系映射起来。有一个对象关系映射器（JPA是实现ORM的标准，Hibernate是其中一个实现），它知道如何在数据库表示和对象图表示之间来回转换数据，以便开发人员可以操作对象而不是数据库行。

对于那些认为业务逻辑不应该成为领域模型的一部分的人，这里是来自Java Persistence with Hibernate书中3.1.2节的另一个引用：

领域模型中的实体应该封装状态和行为。例如，用户实体应定义客户的姓名和地址以及计算物品运费（针对该特定客户）所需的逻辑。领域模型是一个丰富的对象模型，具有复杂的关联、交互和继承关系。关于使用面向对象技术处理领域模型的有趣而详细的讨论可以在《企业应用架构模式》（Fowler, 2003）或《领域驱动设计》（Evans, 2003）中找到。

在本书中，我们不会过多地谈论业务规则或领域模型的行为。这并不是因为我们认为它不重要，而是因为这个问题大多与持久性无关。我们关注的是实体的状态是持久的，因此我们集中讨论如何最好地在领域模型中表示状态，而不是如何表示行为。例如，在本书中，我们不关心销售物品的税款如何计算，或者系统如何批准新用户账户。我们更关心用户与他们销售的物品之间的关系如何表示并保持持久。我们将在后面的章节中重新审视这个问题，每当我们更深入地研究分层应用程序设计和逻辑与数据访问的分离时。

显然，Hibernate开发者认为它是一种可行的替代方案，尽管在典型的企业开发中似乎不是常见的方法。

- Nathan Hughes

---

我在4年后才明白这个答案的价值。谢谢，非常好的答案！ - Koray Tugay

Answer 2

我只是在Koray Tugay另一个问题的相关答案中添加了这个回答。

在Java EE中，JPA实体通常是由JPA容器管理的Bean。该容器在任何Java EE认证的应用程序服务器中都提供。

每个实体对象是RDBMS实例中一个或多个表状态的内存表示。事务中托管实体的每个状态修改将自动由容器处理，并映射为针对数据库执行的SQL命令。因此，您无需担心域模型的持久性部分。只需修改相应的Java对象（实体）状态，就会自动反映到数据库中。 （当然，这不是魔法，也有其自身的缺陷。） 每个实体都是与数据源关联的持久性单元的一部分，为其提供连接池。

一个持久化单元由许多 EntityManager 实例管理。 EntityManager 负责管理与关联的持久化单元所有实体的内存表示; 至少是目前从数据库加载的实体。 通常每个线程（~每个http请求）都有一个 EntityManager 实例。

当使用容器管理的EntityManager（即通过@PersistenceContext注入）时，容器将自动在所有涉及持久性单元操作的bean（控制器/服务/ dao /等）之间传播事务上下文。

（最后一句话的意思是，在遇到@transactionnal注释时，它会打开事务，并且在当前方法调用期间执行的任何bean的每个方法都将成为同一事务的一部分。 事务将在方法执行结束时提交（或回滚）。）

- Gab

Answer 3

这是一个领域对象的状态。

持久化实例在数据库中具有表示和标识符值。它可能刚刚被保存或加载，但根据定义，它处于会话范围内。

例如，在Java ORM 框架Hibernate中查看对象的状态。

免责声明：这仅供参考。

- Suresh Atta

---

如果这是一句引语，请附上您找到它的原始位置。 - Luiggi Mendoza

@KorayTugay，看起来你正在以自己的方式学习所有东西。虽然这很好（我鼓励你这样做），但你需要学会一些概念是基于商业或高层次概念而不是技术，就像我在评论中回答你的问题时提供的第一个链接所示。 - Luiggi Mendoza

@NoobUnChained，你错了，业务逻辑应该写在控制器/业务逻辑类/组件中，比如EJB或Spring的@Component（只是为了举例）。另一方面，领域对象用于表示应用程序中的实体。 - Luiggi Mendoza

感谢您的更正@LuiggiMendoza，但我没有理解您的最后一条评论。 - Suresh Atta

@Luiggi：你对NoobUnChained的评论描述了典型做法，但过分夸大了业务逻辑永远不可能进入域的说法。请看我在这里回答中添加的引用以获取不同的观点。 - Nathan Hughes