领域建模中的对象如何睡在数据库中

刚刚注册了一个新的账号，这已经是我注册的第二个账号了，第一个账号的用户名和密码忘了，见笑！在Jdon已经很久了，时不时的就上来看看banq老师和各位道友的帖子其中感受颇深，我学习Java已经有些年头了，无奈一直在使用过程式的开发，程序中几乎除了DAO就没有别的什么逻辑操作了，呵呵，我知道这是和面向对象想抵触的，但是系统不是我设计所以我才感觉无奈。
为了进入状态扯了一些废话请见谅，是在受不了每个程序除了DAO还是DAO，所以我决定自己使用面向对象的思想进行一些设计，在这当中我发现了很多问题，当要持久化对象的时候才发现，使用面向对象的思想在数据库中似乎很困难，拿权限模型来说吧，我是这样设计的有用户，用户组，角色，权限几个对象，我给角色定义为一个抽象角色，所以就需要一些子类角色进行继承，那持久化的时候如何设计表？毕竟现在要是想保持对象的状态还是的放在数据表中啊，这是一点，还有我们正常的思维一个用户组可以具有几种角色，一个角色拥有几个权限这些都是集合的关系，保持这些状态的时候数据库又应该如何做？数据库和面向对象思想的冲突决定了这些思维上的问题，ORM框架似乎可以进行解决，但是问题是有些系统不能使用ORM框架，在领域中的对象往往有自己的方法，我要将这样的充血对象持久化的时候难道需要先提取出来一个PO(只含有充血对象属性的类)，然后进行持久化吗？
也许我对领域建模还没有深入的理解，可能一些解决的办法我还没有发现或是领悟，所以希望banq老师和各位道友给予帮助。谢谢大家

[该贴被zzxsky1986于2008-11-25 17:55修改过]
[该贴被zzxsky1986于2008-11-25 17:57修改过]

我在下面帖子说了：

模型对象就通过缓存常驻内存，模型对象通过共享方式为前台界面服务，模型对象就脱离数据库存在，这样，在业务过程中数据的存储就不是核心，只要对内存模型对象进行操作就可以，将来会发展到：模型对象自己会定时把自己存储到数据库（以备不测，在系统空闲时操作，可以在自己被垃圾回收之前持久化，多美妙），这个不用我们程序去操心。

Hibernate还是没有做到自动持久化这个层面，还要事件触发save等动作，不过离自动也很近了，比如在模型对象的set方法中放入观察者setChanged之类，一旦事件触发set方法，就触发观察者自动保存，不过这样有可能性能不佳，set方法频繁调用，而且模型对象就不干净了。

http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=34936&message=23118511#23118511

那以banq老师的意思，目前我们还是只能痛苦的忍受着OO和ER这个两个截然相反的思想混合在一起的做法进行软件的设计了，毕竟对于中小型的系统软件服务器是不可能不关机的，也很有可能会当机，那么想要保存对象的状态只能依靠数据库，对于对象状态的持久化保存希望在不久的将来能够摆脱数据库的纠缠，我确实能够感觉到OO的思维方式是符合客观世界的，客观世界是在不断变化的，那么利用正常的思维(OO思维)是可以做到随着客观世界一切进行变化的，扩展，改造的。



[该贴被zzxsky1986于2008-11-26 09:54修改过]

>服务器是不可能不关机的，也很有可能会当机
这个新的持久层框架可以自由定义保存的频率和触发方式，比如每2秒发现更新就启动另外线程进行保存。这种频率对于中小企业应该足够，也可以设置一个flush命令，一次性全部保存，这些都是灵活设计，总之，减少程序员在开发过程中照顾对象的睡觉这个事件，减轻程序员开发负担，这样才能真正杜绝程序员数据库编程思维。我相信这样的新式持久层框架会出现的。

>只能痛苦的忍受着OO和ER这个两个截然相反的思想混合在一起的做法进行软件的设计了

Hibernate可以帮助我们减轻这种痛苦，结合OSIV，只要调用一个save就可以了。

因为我们意识到了问题，所以我们痛苦，而更多人没有意识到，他们没有痛苦，因为他们只有一种思想：数据库,甚至把Hibernate当作数据库工具来使用，我真佩服他们的悟性，没治了。


[该贴被banq于2008-11-26 15:54修改过]

程序的实现过程中总有一些儿“脏活”，通常能做的只是把他们尽量的局限在一个小范围内不会产生污染的扩散。OO是封装的思想，对于“脏活”的封装也是一部分了。

“一旦事件触发set方法，就触发观察者自动保存”
在StatefulBean里的状态不就这样干的吗？但是必须保证独占性。