持久化对象的概念

1.简介

该概念面向希望利用 IS 7 持久对象层(数据层)创建新持久对象或重用现有对象的开发人员.在处理持久对象开发之前，Intershop建议熟悉 Enfinity 定义语言、EDL 建模和业务对象开发。

持久对象和建模

由磁带编码的功能通常需要在数据库中持久存储信息。如果不存在合适的数据库表，则必须创建新表。为了使管道等应用程序组件可以访问这些数据库表，需要在持久层创建新的持久对象。可能还需要实现额外的管理器类，这些管理器类对新的持久对象进行操作。

2.持久对象

(1)持久对象类

持久对象 (PO) 是用于将数据存储到数据库或从数据库读取数据的 Java 对象。采购订单由四个(可选五个)文件组成：

表示持久对象的 PO 类 各个类都带有后缀PO，例如ProductPO.java.

描述对象-关系映射(OR 映射)的描述符文件 描述符文件的文件扩展名为*.orm，例如ProductPO.orm.

用于生命周期管理的工厂类各个类都带有后缀POFactory，例如ProductPOFactory.java.

用于标识持久对象的关键类 各个类都带有后缀POKey，例如ProductPOKey.java.

如果模型定义了一个 key 一个备用 key-class相应的类带有后缀POAlternateKey，例如. .Preference DefinitionPOAlternateKeyjava

这些类通常是墨盒内部封装的一部分，不会公开。除了这个抽象基类的持久对象可能参与公共 API。

(2)对象关系映射

将类映射到表在 Intershop 7 中，单个 PO 映射到单个表或数据库视图。Intershop 7 中未使用其他可能性，例如将类映射到连接表或其他结构。PO 的每个实例对应于一行。类的属性对应于列。类的主键属性映射到表的主键，即用于唯一标识行的列(或列)。

映射和继承关系Intershop 7 使用一种方法，根据这种方法，只有叶类映射到数据库中，而超类必须是抽象的。叶类的表既包含从超类继承的属性，也包含它们自己的属性。

(3)持久对象的基类

Intershop 7 中的许多 PO 派生自通用基类RegionalSettingsPOor ExtensibleObjectsPO，它们都是 com.intershop.beehive.core.capi.domain 的一部分。PersistentObjectPO自动提供一系列属性，确保以与 Intershop 7 机制和流程兼容的方式定义这些属性。自动提供的属性 RegionalSettingsPO包括：

AUUID作为主键

乐观控制属性 ( oca)

domainID属性

这是用于引用持久对象所属域的外键属性。派生自的类 RegionalSettingsPO自动继承获取和设置 的domainID方法，以及获取和设置 . 引用的持久对象的域实例的方法domainID。

域getDomain () 
void  setDomain (Domain aDomain) 
String getDomainID () 
void  setDomainID (String aDomainID)

此外，ExtensibleObjectPO(的子类RegionalSettingsPO)提供了允许开发人员在运行时添加自定义属性的功能，如参考 - 持久对象的属性 - 可扩展对象属性中所述。

(4)持久对象类的建模示例

以下 EDL 片段定义了一个持久对象，包括与其他对象的依赖关系。

命名空间 com.intershop.training.bc_warehouse.internal
{
  orm类 WarehousePO 扩展 ExtensibleObjectPO 实现 Warehouse
     {
      索引（地址ID）；
      属性名: string< 256 > 必填；
      属性位置：字符串< 256 >；
      属性容量: int ;
      属性描述：字符串本地化；
      属性地址ID：uuid；
      依赖地址：地址处理程序“com.intershop.beehive.core.capi.profile.ProfileMgr”
      {
        外键（addressID）；
      }
      关系 stockItemPOs : StockPO[ 0. .n] 逆仓库PO实现stockItems；
    }
}

3.持久对象之间的关系

通常，您的对象模型由一组不独立的 PO 组成，而是以各种方式连接。在对象模型中，类之间的这些连接被建模为关系或依赖关系。

以下部分更详细地描述了关系的所有方面。

(1)关系类型：关系和依赖关系

Intershop 7 基于两种基本的关系类型：

关系

关系表示类之间的双向语义连接。

以下 EDL 片段定义了两个对象WarehousePO和StockPO. 侧边的关系定义WarehousePO：

关系 stockItemPOs : StockPO[ 0. .n]
逆仓库PO实现stockItems；

侧面关系定义StockPO：

关系仓库PO: WarehousePO[ 1. . 1 ]
反向 stockItemPOs 实现仓库
{
外键（仓库ID） -> （UUID）；
}

依赖关系

依赖关系表示类之间的单向关系。在这种情况下，“单向”意味着该关系只能在一个方向上导航。依赖关系通常用于在不同磁带的持久类之间建立关系。

以下 EDL 片段(来自WarehousePO)对连接WarehousePO和Address. 它表示我们只能从WarehousePOto导航关系，而Address不是相反。

依赖地址：地址处理程序
“com.intershop.beehive.core....
capi.profile.ProfileMgr”
{
外键（addressID）；
}

与关系相比，依赖关系在内部以非常不同的方式处理。依赖项未在 ORM 部署描述符文件中注册，它们不需要重新创建引用的类。因此，依赖关系可用于将自定义 PO 类链接到 Intershop 7 提供的 CAPI 对象(例如Product)。

(2)关系的多样性

根据关系每一方的多重性类型，通常区分三种基本类型的关系：

一对一

允许 [0..1] 到 [1..1];[1..1] 到 [0..1] 和 [0..1] 到 [0..1]。由于鸡或蛋的困境，禁止 [1..1] 到 [1..1] 的关系。

一对多

允许 [1..1] 到 [0..n] 和 [0..1] 到 [0..n]。而 [0..1] 到 [1..n] 不是一个实际已知的用例。

多对多

多对多关系总是需要一个连接表来进行映射。

对于关系，多重性在定义中声明。对于依赖项，多重性仅由代码间接定义

1)一对多关系

一对多关系在关系数据库设计中很常见，允许以经济的方式表示复杂的数据集。例如，每个 WarehousePO 实例都指向属于它的 StockPO 实例。同样，每个StockPO指向它的WarehousePO.

为了将仓库和库存数据关联起来，表中需要一个特殊的列，为每个实例StockPO标识正确的实例。这个特殊的列作为外键，它通常映射到相关表的主键，在我们的例子中，表。WarehousePOStockPOWarehousePO回到关系的表示，这意味着您必须引入一个特殊的属性，该属性用作外键并映射到相关 PO 类的主键属性上。在一对多关系中，外键在类中定义多面, 例如, StockPO, 它映射到类的主键上一边，例如，WarehousePO。

EDL 片段来自多面，例如StockPO：

索引（仓库ID）；
属性warehouseID: uuid 必填 只读；
关系仓库PO: WarehousePO[ 1. . 1 ] 逆stockItemPOs实现仓库
{
  外键（仓库ID） -> （UUID）；
}

对于一对多关系，代码生成器为所涉及的两个类创建特殊方法，多面和上的课一边. 方法因所考虑的类别而异。

多端方法

为类生成的方法多面，例如，StockPO允许您访问代表类的角色一边，例如，WarehousePO。

public WarehousePO getWarehousePO ()

单方面的

方法一边，例如，WarehousePO代码生成器创建一个方法来访问代表类的相关角色多面，例如StockPO：

公共集合getStockItemPOs () 
公共迭代器createStockItemPOsIterator ()

此外，代码生成器创建关系包装器方法。这些方法检查特定元素是否参与关系：

public  boolean  isInStockItemPOs (StockPO anElement) 
public  int  getStockItemPOsCount ()

2)依赖

依赖关系是与实现的类的单向关系PersistentObject。单向意味着它们只能在一个方向上遍历：从源类到目标类。目标类总是有多个0..1. 在下面的 EDL 片段WarehousePO中，依赖关系表示 的每个实例WarehousePO都与 的一个实例相关联Address。与正常的关联关系相反，依赖关系没有表达相反的陈述，即每个实例Address都可以与一个或多个实例相关联WarehousePO。Address不知道两个实体之间的存在和WarehousePO 关系。但是，如果业务逻辑需要此功能，则可以确定所有实例WarehousePO通过使用查询与给定地址相关。结果可能包含许多实例或仅包含一个实例，如果这受到实现的限制。因此，依赖于实现，依赖关系可以是一对多或一对一的关系。

依赖地址：地址处理程序“com.intershop.beehive.core.capi.profile.ProfileMgr”
{
  外键（addressID）；
}

代码生成器为依赖项创建的代码只影响源类，而不影响目标类。Address因此，如果您创建的新 PO 与无法重新编译或更改的现有对象(例如 )相结合，则依赖关系特别有用。

另一个常见的用例是隐藏与单侧 PO位于同一墨盒中的 PO 的关系，因为它不打算使该 PO 的这种关系“公开”。在这种情况下，不能定义处理程序，并且调用 PO 的工厂以通过主键查找来定位相关实例。另一个用例是避免创建与海量数据的双向关系。

以下 EDL 片段WarehousePO声明了外键属性addressID：

属性地址ID：uuid；
索引（地址ID）；

通常，依赖项将自定义 PO 与由 CAPI 接口表示的其他持久对象连接起来。

在我们的示例中，依赖项将自定义 POWarehousePO与标准 Intershop 7 CAPI 接口连接起来Address。在对这样的依赖项进行建模时，您必须提供管理器的符号名称，该管理器提供对 CAPI 接口后面对象的访问。

代码生成器使用提供的管理器来创建访问器方法。

代码生成器创建一个 getter 方法，它允许您访问特定源类实例所连接到的目标类实例，以及一个用于将源实例分配给目标实例的 setter 方法。例如，对于与 连接的依赖WarehousePO，Address生成如下方法：

公共地址getAddress ()
 {
     if (getAddressIDNull())
    {
        返回 空值；
    }
    ProfileMgr 工厂 = (ProfileMgr) NamingMgr.getInstance().lookupManager(ProfileMgr.REGISTRY_NAME);
    return (Address) factory.resolveAddressFromID(getAddressID());
}
public  void  setAddress (地址地址)
 {
     if (address == null )
    {
        setAddressIDNull( true );
    }
    别的
    {
        setAddressID(address.getUUID());
    }
}

3)多对多关系

多对多关系在 Intershop 7 应用程序中很常见。例如，考虑产品和供应商之间的关系：每个供应商可能交付不止一种产品，而每种产品可能由不止一个供应商交付。或者，组合产品以形成新产品(例如，计算机、鼠标和监视器)的产品捆绑包可以捆绑成完整的计算机包。这里也存在多对多关系，因为每个产品包可以包含许多不同的产品，并且每个产品都可以是不同产品包的一部分。

考虑下图，它表达了产品和产品包(同样是产品)之间的关系。通过 assignment class ，通过将(引用产品捆绑包的 UUID 的外键属性)的值与(引用捆绑包中的产品的外键属性)的值BundleAssignmentPO配对，产品捆绑包与产品配对。两个外键都映射到( ) 的主键。bundleIDproductIDProductUUID

(3)CAPI接口和持久对象

在许多用例中，持久对象实现了 CAPI 接口。该接口也可以建模或作为外部类型导入。以下 EDL 片段中显示了在自定义 PO 之上建模的一组 CAPI 接口的示例：

导入 “enfinity:/demo/edl/com/intershop/demo/capi/Warehouse.edl”；
命名空间 com.intershop.demo.internal
{
  orm class  WarehousePO  extends  ExtensibleObjectPO  implements  Warehouse  { ... }
}
导入 “enfinity:/demo/edl/com/intershop/demo/capi/Stock.edl”；
命名空间 com.intershop.demo.internal
{
  oca orm class  StockPO 实现 Stock  { ... }
}

PO WarehousePO 实现了接口Warehouse。

PO StockPO 实现了 Stock 接口。

接口是 capi 包的一部分，而实现类是内部包的一部分。

请注意，PO 和接口使用不同的基类：

PO WarehousePO 继承自抽象类com.intershop.beehive.core.capi.domain.ExtensibleObjectPO。

接口 Warehouse 扩展了接口com.intershop.beehive.core.capi.domain.ExtensibleObject。