什么是持久性对象？ [英] What is a persistence object?

问题描述

我正在阅读Java EE教程并此处在开头看这句话：

I am reading the Java EE Tutorial and here I see this sentence in the begining:

实体是一个轻量级持久域对象。

An entity is a lightweight persistence domain object.

我搜索了持久性对象，但找不到明确的解释。

I have searched for persistence object but could not find a clear explanation.

究竟什么是持久性域对象？

推荐答案

Java EE假设名为域模型。域模型由表示实体的对象组成，其中实体具有与其相关的身份。商业。 （例如，如果您在银行工作，您的域可能涉及账户，客户，控股和贷款等事项）。

Java EE assumes something called a Domain Model. The domain model consists of objects representing entities, where an Entity is something that has an identity relevant to the business. (For example, if you work at a bank your domain might involve things like Accounts, Customers, Holdings, and Loans).

以下是Bauer和King的 Java Persistence with Hibernate 描述域模型的引用：

Here is a quote from Bauer and King's Java Persistence with Hibernate describing domain models:

3.1.1。分析业务领域

3.1.1. Analyzing the business domain

软件开发工作从分析问题
域开始（假设没有遗留代码或遗留数据库已经存在
） 。

A software development effort begins with analysis of the problem domain (assuming that no legacy code or legacy database already exists).

在此阶段，您在问题领域专家的帮助下，确定与软件系统相关的主要实体
。实体
通常是系统用户理解的概念：付款，
客户，订单，项目，出价等等。一些实体可能是
用户想到的不太具体的东西的抽象，例如
定价算法，但即使这些也通常可以理解为
用户。所有这些实体都可以在
业务的概念视图中找到，我们有时将其称为业务模型。面向对象软件的开发人员和
架构师分析业务模型，并且
创建一个面向对象的模型，仍然处于概念层面（没有
Java代码）。这个模型可能只是在开发人员心目中只存在于
的心理图像，或者它可能像计算机辅助软件工程（CASE）$创建的UML
类图一样精细。 b $ b工具，如ArgoUML或TogetherJ。用UML表示的简单模型是
，如图3.1所示。

At this stage, you, with the help of problem domain experts, identify the main entities that are relevant to the software system. Entities are usually notions understood by users of the system: payment, customer, order, item, bid, and so forth. Some entities may be abstractions of less concrete things the user thinks about, such as a pricing algorithm, but even these would usually be understandable to the user. All these entities are found in the conceptual view of the business, which we sometimes call a business model. Developers and architects of object-oriented software analyze the business model and create an object-oriented model, still at the conceptual level (no Java code). This model may be as simple as a mental image existing only in the mind of the developer, or it may be as elaborate as a UML class diagram created by a computer-aided software engineering (CASE) tool like ArgoUML or TogetherJ. A simple model expressed in UML is shown in figure 3.1.

此模型包含您在任何典型的
拍卖中必定会找到的实体system：category，item和user。实体及其
关系（可能还有它们的属性）都由
这个问题域模型表示。我们将这种面向对象的
模型称为问题域中的实体，仅包含用户感兴趣的
实体，即域模型。这是现实世界的
抽象视图。

This model contains entities that you're bound to find in any typical auction system: category, item, and user. The entities and their relationships (and perhaps their attributes) are all represented by this model of the problem domain. We call this kind of object-oriented model of entities from the problem domain, encompassing only those entities that are of interest to the user, a domain model. It's an abstract view of the real world.

分析和设计域模型背后的激励目标
是捕捉精华的本质
应用程序用途的商业信息。

The motivating goal behind the analysis and design of a domain model is to capture the essence of the business information for the application's purpose.

理想情况下（在一个名为域驱动设计）这些域对象有两个特性：它们不知道持久性或事务等基础设施问题，它们包含逻辑实现在业务处理过程中操作它们时发生的状态转换;这些组合意味着业务逻辑可以与基础架构分开测试。在现实世界中，更典型地看到不包含任何业务逻辑的贫血域对象 ，业务逻辑最终都在交易脚本中。

Ideally (in an approach called Domain-Driven Design) these domain objects have 2 features: they do not know about infrastructure concerns like persistence or transactions, and they contain logic implementing the state transitions that occur when they are manipulated during the course of business processing; the combination of these means that business logic can be tested separately from infrastructure. In the real world it's more typical to see anemic domain objects which do not contain any business logic, the business logic all ends up in transaction scripts.

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

Anyway the idea is you have a domain model made up of persistent entities. There is some kind of configuration (annotations or XML files or whatever) which maps the entities and their attributes to tables and columns in a database, and which maps the relationships between the entities. There's an Object-Relational Mapper (JPA is a standard for implementing ORMs, Hibernate is one such implementation) that knows how to convert the data back and forth between the database representation and the object-graph representation, so that the developer can manipulate objects instead of database rows.

对于声称业务逻辑不应该是域模型的一部分的人，这里是 Java Persistence with Hibernate 一书中的另一个引用，在3.1.2节中：

For people who claim that business logic should not be part of the domain model, here is another quote from the Java Persistence with Hibernate book, in section 3.1.2:

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

The entities in a domain model should encapsulate state and behavior. For example, the User entity should define the name and address of a customer and the logic required to calculate the shipping costs for items (to this particular customer). The domain model is a rich object model, with complex associations, interactions, and inheritance relationships. An interesting and detailed discussion of object-oriented techniques for working with domain models can be found in Patterns of Enterprise Application Architecture (Fowler, 2003) or in Domain-Driven Design (Evans, 2003).

在本书中，我们对业务规则或者我们的域模型的行为约
没什么好说的。这不是因为我们认为
不重要;相反，这种担忧主要与持久性问题
正交。这是我们实体的状态是持久的，所以
我们将讨论集中在如何最好地表示我们的
域模型中的状态，而不是如何表示行为。例如，在这个
的书中，我们对计算销售商品的税额或者b $ b b系统如何批准新用户帐户不感兴趣。我们更感兴趣的是
，用户与他们销售的商品之间的关系是如何代表
并保持持久性。每当我们仔细研究分层应用程序设计
以及逻辑和数据访问的分离时，我们将在后面的
章节中重新讨论这个问题。

In this book, we won't have much to say about business rules or about the behavior of our domain model. This isn't because we consider it unimportant; rather, this concern is mostly orthogonal to the problem of persistence. It's the state of our entities that is persistent, so we concentrate our discussion on how to best represent state in our domain model, not on how to represent behavior. For example, in this book, we aren't interested in how tax for sold items is calculated or how the system may approve a new user account. We're more interested in how the relationship between users and the items they sell is represented and made persistent. We'll revisit this issue in later chapters, whenever we have a closer look at layered application design and the separation of logic and data access.

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

So apparently the Hibernate developers see it as a viable alternative, although it doesn't seem to be a common approach in typical enterprise development.

这篇关于什么是持久性对象？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！