状态模式和hibernate问题请教

power1128 07-12-01
              

不知道大家在使用状态模式和hibernate这种orm工具时有没有遇到这种问题:
比如有Context,State1,State2这几个类,在我的设计里,State1和State2是值对象,而且继承接口State.在Context里有对State的引用。State接口的几个方法接受Context参数。每个具体的State实现有一个类变量code.
数据库表设计为一个表,有一个字段存储整形数字表示状态。此时我想把状态对象的类变量映射到这个字段。但是实在找不到好方法。大家帮我看看,是我的思路有问题还是hibernate不能满足这种需要?(不想修改数据库表结构,也不想将状态对象由值对象变为实体对象)

              

banq
2007-12-03 11:13

只要你抓住对象,Hibernate是最好使用了。Hibernat中文是冬眠,意识就是对象的冬眠(持久化)。

你可以将你每个状态之类直接冬眠,或者,将state1和state2等值对象和其关联的实体一起冬眠持久化(通过Hibernate关联配置)。后者符合DDD,推荐使用。

power1128
2007-12-03 22:32

banq大哥,我理解 你的意思,我现在是在实现的时候遇到了问题。
不知道我理解的是否正确:在Hibernate里,如果一个类对应了一个map文件,是否说明这个类是一个实体对象?因为我这个状态模式里的状态对象,我认为是值对象,应该用Component映射,但是component这种映射好像并不支持继承映射,这就是我的问题,还请banq大哥指教

banq
2007-12-04 08:44

>如果一个类对应了一个map文件,是否说明这个类是一个实体对象
正好相反,只有确定一个类是实体对象,才配置一个map文件。

那么如果确定一个类是实体对象呢?,这就是系统分析建模了,在Evans DDD中有这样定义,比如最近讨论的广交会网站分析案例大部分就是确定哪些实体类。
http://www.jdon.com/article/33006.html

比如:订单和订单状态就是这样的关系,订单状态作为实体订单的值对象,是和订单这个实体一起冬眠的。

以下是有感而发,不针对楼主:
Hibernate只是架构技术,属于计算机软件技术,计算机软件技术是为客观需求服务的,我们技术人员千万不能在软件技术领域打转转,忽视需求,导致因果关系倒置,看不清本质,陷入猫追尾巴的圈子,所以,领域建模才是技术软件人员必须掌握的基础知识,虽不一定进行系统分析,但是可以开拓眼界,对技术能够迅速抓住本质。
[该贴被banq于2007-12-04 13:01修改过]

power1128
2007-12-05 17:58

banq大哥,是这样的,我在进行需求分析和设计的时候,的确没有想过实现细节的东西,所以运用了状态模式.
因为这个系统既是我设计,也是我实现的.在具体编码阶段,我想把Context和它的状态实例持久,然后以后再从持久的地方取回来.而且我也是刚开始用Hibernate,还不太熟,因此在Context的map文件里,我把这个State类用Hibernate的Component映射,这样持久没有问题,但是将来从持久层再把它取回来时,这个状态对象应该时状态类的某个具体子类的实例,但是Component又没有配置subclass的地方(还是有类似的功能?我查了dtd,没发现subclass),因此Hibernate再加载的时候又怎么能知道生成哪个具体子类的实例呢?

4Go 1 2 3 4 下一页