看到jBPM中大量使用了subclass的用法,应该说这个是比较OO的,设计的非常合理。
(一)、首先先去看看Hibernate的subclass:
1.对于“每一个类继承树对应一个表”的策略来说,就需要使用<subclass>定义。
<subclass>
name="className" //子类的全名
discriminator-value="discriminator-value" //辨别标识,一个用于区分每个独立的子类的值
proxy="proxyInterface" //指定一个类或接口,在延迟加载时作为代理使用
lazy="true|false"
dynamic-update="true|false"
dynamic-insert="true|false"
entity-name="entityName"
node="element-name">
<property ..../>
......
</subclass>
2.每个子类都应该定义它自己的持久化属性和子类。<version>和<id>属性可以从根父类继承下去。在一棵继承树上的每个子类都必须定义一个唯一的discriminator-value。如果没有指定,就会使用Java类的全限定名。
3.必须在子类的影射中指定extends属性来指定已影射的超类。
(二)在jBPM中的使用
1.在jBPM的definition组的类机构中就采用上述的技术。其中ModuleDefinition是作为抽象父类存在的,而ContextDefinition、FileDefinition、LoggingDefinition、SchedulerDefinition、MgmtDefinition类是做为subclass存在的。
2.在父类中使用了discriminator鉴别器的技术:在继承策略中的“一个对象继承树应对应一个表”的策略中,<discriminator>元素是必须的。鉴别器字段包含标志值,用于告知持久层应该为某个特定的行创建哪一个类别的实例。例如:
父类的影射片段:
<discriminator type="char" column="CLASS_"/>
<!-- M : org.jbpm.module.def.ModuleDefinition -->
<!-- C : org.jbpm.context.def.ContextDefinition -->
<!-- F : org.jbpm.file.def.FileDefinition -->
<!-- L : org.jbpm.logging.def.LoggingDefinition -->
<!-- I : org.jbpm.scheduler.def.SchedulerDefinition -->
<!-- T : org.jbpm.taskmgmt.def.TaskMgmtDefinition -->
<!-- : -->
<!-- : -->
3.鉴别器字段的实际值是根据<class>和<subclass>元素中的discriminator-value属性得来的。
例如:
父影射文件:
<class name="org.jbpm.module.def.ModuleDefinition"
table="JBPM_MODULEDEFINITION"
abstract="true"
discriminator-value="M"
lazy="false">
子影射文件:
<subclass name="org.jbpm.context.def.ContextDefinition"
extends="org.jbpm.module.def.ModuleDefinition"
discriminator-value="C"
lazy="false">
</subclass>