该概念面向希望利用 IS 7 持久对象层(数据层)创建新持久对象或重用现有对象的开发人员.在处理持久对象开发之前,Intershop建议熟悉 Enfinity 定义语言、EDL 建模和业务对象开发。
由磁带编码的功能通常需要在数据库中持久存储信息。如果不存在合适的数据库表,则必须创建新表。为了使管道等应用程序组件可以访问这些数据库表,需要在持久层创建新的持久对象。可能还需要实现额外的管理器类,这些管理器类对新的持久对象进行操作。
持久对象 (PO) 是用于将数据存储到数据库或从数据库读取数据的 Java 对象。采购订单由四个(可选五个)文件组成:
表示持久对象的 PO 类 各个类都带有后缀PO,例如ProductPO.java.
描述对象-关系映射(OR 映射)的描述符文件 描述符文件的文件扩展名为*.orm,例如ProductPO.orm.
用于生命周期管理的工厂类各个类都带有后缀POFactory,例如ProductPOFactory.java.
用于标识持久对象的关键类 各个类都带有后缀POKey,例如ProductPOKey.java.
如果模型定义了一个 key 一个备用 key-class相应的类带有后缀POAlternateKey,例如. .Preference DefinitionPOAlternateKeyjava
这些类通常是墨盒内部封装的一部分,不会公开。除了这个抽象基类的持久对象可能参与公共 API。
将类映射到表在 Intershop 7 中,单个 PO 映射到单个表或数据库视图。Intershop 7 中未使用其他可能性,例如将类映射到连接表或其他结构。PO 的每个实例对应于一行。类的属性对应于列。类的主键属性映射到表的主键,即用于唯一标识行的列(或列)。
映射和继承关系Intershop 7 使用一种方法,根据这种方法,只有叶类映射到数据库中,而超类必须是抽象的。叶类的表既包含从超类继承的属性,也包含它们自己的属性。
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)提供了允许开发人员在运行时添加自定义属性的功能,如参考 - 持久对象的属性 - 可扩展对象属性中所述。
以下 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;
}
}
通常,您的对象模型由一组不独立的 PO 组成,而是以各种方式连接。在对象模型中,类之间的这些连接被建模为关系或依赖关系。
以下部分更详细地描述了关系的所有方面。
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)。
根据关系每一方的多重性类型,通常区分三种基本类型的关系:
一对一
允许 [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
在许多用例中,持久对象实现了 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。
你适合学Java吗?4大专业测评方法
代码逻辑 吸收能力 技术学习能力 综合素质
先测评确定适合在学习