关于OO与关系数据库阻抗的谈论

作者：yongbuyanbai 发表时间：2008年07月28日 10:38 回复此消息回复

原贴网址： http://www.jdon.com:8080/jivejdon/thread/34411.html
标签列表 oo思维(101)      对象数据库阻抗(49)     

小弟初到JDON，看了bang和道友的经典帖子感觉真的不错，看完后小弟有个疑问想请教各位：
对于我们采用OO的设计理念进行的项目开发，对于采用DDD的设计方式，我们设计出的内容是完全不考虑数据库的，最后是在仓储中进行数据访问，那么疑惑出来了，对于以前说的表示层的VO和PO如果不匹配的话，或者一个VO中关联了多个PO中的内容，这样的情况我们如何去改善。而且在设计业务模型的时候(实体)，对于与实体相关联的逻辑我们应该放在实体中还是放在外面，对于采用充血方式开发的实体，对于类似Hibernate这样的映射框架来说可以吗？因为在用Hibernate的时候，很多时候仅仅是用get，set方法来定义一个实体，而且与表的关联想对应的。实际我个人认为，这些问题的根源还是因为了OO设计思想与当前关系数据库的不匹配引起的，所以导致小弟对设计实体时候的疑惑，因为以往的设计还是会采用bang所说的那种过程式开发的通病方式进行设计，希望bang以及各道友给予指点

这个主题共有 15 回复 ／ 2 页 1 2 ►
re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 11:21 回复
freebox 发表文章: 279/ 注册时间: 2008年03月01日 01:08
我觉得是先有业务对象，然后需要持久的时候才有持久对象，需要传输的时候才有VO，测试领域的时候好像不需要VO和PO，VO可以根据业务对象组合或只要部分定义，跟PO没多大关系，尽管有些定义域是一致的。

re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 11:25 回复
yongbuyanbai 发表文章: 49/ 注册时间: 2008年07月31日 17:46
但是我们最终的设计是要将持久的数据保存到数据库中，而这种保存必须要考虑到的就是数据库，前期的设计不用考虑数据库，但是在后期设计仓储的时候要考虑这个问题，并且这个时候如果发现设计的业务模型对于存储到数据库，或者对于前端显示的VO有困难或者一个VO中需要多方面的PO去关联怎么解决呢？我还是比较迷惑的，请给予解答，谢谢！

关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 14:04 回复
yongbuyanbai 发表文章: 49/ 注册时间: 2008年07月31日 17:46
小弟是想说的，对于我们采用完全OO的思想设计系统的时候，可以抛弃以往的数据库建模，不用什么ER图之类的，而采用OO思想，利用UML用例图等等来设计业务领域模型，但是我们最终还是要将需要持久的信息存储到数据库，小弟在这个地方就产生了迷惑，如何将这些持久的业务模型转化为数据库中的表记录信息，这种转变必然是在程序中考虑的，这个时候的持久化我们应该如何去做，也会利用所谓ORM映射工具，在我用Hibernate的时候都是一些贫血的PO在进行操作，这些PO按照都是存在数据库影子在里面，并不是完全的OO设计，所以这种从业务领域模型到持久化这个过渡我们应该怎么做，必须得通过SQL或者Hibernate中的HQL来进行，这其中的思想请banq和道友帮解惑下，在此小弟先谢过。

re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 16:24 回复
freebox 发表文章: 279/ 注册时间: 2008年03月01日 01:08
hibernate auto-ddl。
另外不知您描述的是否是改造遗留系统的故事，如果这样就比较复杂点，以前弄过一个类似的，最终的协商结果是部分结构简易的数据表重建，部分数据表保留待以后调整，虽然至今也没见调整。
而另一个关于VO和PO的问题我认为应该是都和业务对象关联，它们两个并没有直接的联系。
在OO的故事里既然领域模型已经完备了，持久数据利用Hibernate等工具应该比较容易。

回复:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 16:52 回复
banq 发表文章: 9485/ 注册时间: 2002年08月03日 17:08
这个问题起源于你对充血模型的误解，你以为充血模型在代码上就是一定不是表现为set/get，你看到set/get代码就认为这是贫血或失血模型，这有些盲人摸象，就象设计模式中，你指着一个类代码说我看不到设计模式，其实设计概念上模式和模型有时可能具体表现为多个类的实现，表面上贫血，实际上充血，这是符合高内聚，低耦合原则的：

充血模式=set/get类+模式(如Proxy等)+其他类

这个问题我早就在下面贴子谈过：

http://www.jdon.com/jivejdon/forum/messageList.shtml?thread=33948&count=15&start=15




[该贴被banq于2008-07-28 16:56修改过]

re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 17:16 回复
yongbuyanbai 发表文章: 49/ 注册时间: 2008年07月31日 17:46
哦，这个我知道的，但是我迷惑一点的是，对于业务模型的GET和SET方法， 真正与业务有关的逻辑，是放在他们中呢，还是象您说的那样将这个业务实体仍然是类似于贫血模式，但是通过代理等设计模式表现为充血的呢。
如果业务实体中不光含有set和get，而且存在与领域相关的业务逻辑的话，是否对于Hibernate这样的ORM工具可以达到映射（我在其他论坛中看到有人说真正的充血模式在JAVA中很难实现，主要是关联这样的ORM映射工具复杂），还是采用set和get方法，但是象您说的通过设计模式达到看似贫血实际充血的效果呢？

回复:re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 18:23 回复
banq 发表文章: 9485/ 注册时间: 2002年08月03日 17:08
>对于业务模型的GET和SET方法， 真正与业务有关的逻辑，是放在他们中呢，还是象您说的那样将这个业务实体仍然是类似于贫血模式，但是通过代理等设计模式表现为充血的呢。

需要自己多思考，难道OO世界有一个规定，业务逻辑必须放在Java语言的Bean的set/get方法吗？注意：设计高于语言，Beans的set/get是代表设计上的Property，也就是一种特殊的属性，难道能让业务方法压缩放入属性？除了这种向下向内压缩的思维，就不能有向上向外扩充的思维？

所以，要用好 DDD，必须有深刻的模式思维功底，有些人认为有了框架就无需学习模式，其实这是误区，模式不但在建模中需要使用，而且能够培养向上架构思维。

同时需要认清楚分析设计和语言之间的关系：Java作为一个语言平台，Domain Model作为一个分析设计概念，分析和设计之间有鸿沟，不是一一对应，只能从从分析推到设计；同样设计和语言之间也有鸿沟，只能从设计推到语言，反之就不行，不能从语言倒退还原设计的。

具体代码可见JiveJdon3案例。

btw:说什么Java不能实现丰富的Domain Model，这是片面的，我们考虑下面情况，
1.如果一个类需要多台服务器之间传输，你是将所有业务打包一个类(2M更大)，形成所谓形式上的充血模型在多台服务器之间传递快？还是我只将主要实体数据和行为分离，将主要数据在多台服务器之间奔跑快呢？

2.从设计概念上讲，也不能将所有业务方法耦合到一个类中，这和过程编程有什么区别？

3.是不是有一种语言平台能够避免这个问题？我想如果有，它在现阶段就不能解决上述矛盾，除非将来带宽更宽；或者它根本不考虑性能的扩充，只考虑单机（性能上象过去Delphi一样依赖数据库能力）。


[该贴被banq于2008-07-28 18:42修改过]

re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 18:33 回复
yongbuyanbai 发表文章: 49/ 注册时间: 2008年07月31日 17:46
多谢banq和各位指点，小弟明白了些，正如您说的，好多东西都需要去悟。感谢感谢！以后学习中有问题，还要向大家请教！

re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 18:43 回复
yongbuyanbai 发表文章: 49/ 注册时间: 2008年07月31日 17:46
哈，刚发觉我发的帖子有点问题，刚才我说的那句
>对于业务模型的GET和SET方法， 真正与业务有关的逻辑，是放在他们中呢，还是象您说的那样将这个业务实体仍然是类似于贫血模式，但是通过代理等设计模式表现为充血的呢。
我这里说的并不是把业务逻辑放在set和get中，而是说对于业务实体有些人说只含有set和get方法叫做贫血模式，我的意思是业务实体中除了含有get和set方法，业务方法是否可以放在业务实体中，而当这种实体需要“冬眠”的时候，是否利用Hibernate有一定的困难，看了banq那个连接，意思是对于业务实体的业务逻辑可以分离出来，并不一定需要把他们放在业务实体类中，而此时业务实体类仅仅含有表面的特殊属性set/get方法，而其实他们是通过set/get 加上代理等其他类共同实现的充血。这个是看后我的理解。我想问下，如果要是将业务逻辑放在了业务实体中，那这种实体的冬眠在Hibernate中映射有困难吗？我们一般是采用实体中含有业务逻辑，还是分离出来业务逻辑，达到表面贫血，实际充血！谢谢！

回复:re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 20:30 回复
banq 发表文章: 9485/ 注册时间: 2002年08月03日 17:08
>如果要是将业务逻辑放在了业务实体中，那这种实体的冬眠在Hibernate中映射有困难吗？
看看我前面帖子后面部分，从设计上讲这是不对的，这是紧耦合；另外，一个20M的业务实体要进行分布式计算，必须进行序列化，多增加负担，同样冬眠到数据库是不是也很耗费性能（其中也涉及序列化或动态加载）？

注：Hibernate只要配上一个分布式缓存就能实现分布式。
[该贴被banq于2008-07-28 20:31修改过]
[该贴被banq于2008-07-29 09:16修改过]

re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月28日 21:24 回复
freebox 发表文章: 279/ 注册时间: 2008年03月01日 01:08
业务逻辑放在实体中是可以非常容易的应用Hibernate持久化的，但是不宜采用。是不是以前管这个叫有血？
另外网络瓶颈对soa影响也很重大吧。什么时候才有高速网络，至少看电影啥的也方便。

re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月29日 09:40 回复
yongbuyanbai 发表文章: 49/ 注册时间: 2008年07月31日 17:46
想问下对于不建议将业务逻辑写在实体中，如果采用分离，我们应该以怎样的设计思路进行分离，能否指点一二，banq和各位道友的思路真的想好好学习借鉴下。请详细说明下，谢谢了！

回复:re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月29日 16:26 回复
banq 发表文章: 9485/ 注册时间: 2002年08月03日 17:08
>不建议将业务逻辑写在实体中，如果采用分离，我们应该以怎样的设计思路进行分离，能否指点一二

前面说了，请参考JiveJdon3源码，其中帖子和相关其他业务的处理。

其他案例讨论最近一个案例：
http://www.jdon.com/jivejdon/thread/34232.html

Entity中是否可以引用Repository
http://www.jdon.com/jivejdon/thread/31594.html
[该贴被banq于2008-07-31 11:49修改过]

回复:re:关于OO与关系数据库阻抗的谈论 发表: 2008年07月29日 20:12 回复
freeren 发表文章: 69/ 注册时间: 2007年02月15日 09:39
我觉得是先有业务对象，然后需要持久的时候才有持久对象，需要传输的时候才有VO，测试领域的时候好像不需要VO和PO，VO可以根据业务对象组合或只要部分定义，跟PO没多大关系，尽管有些定义域是一致的。

--vo不应该是传输时有的吧，按字面上来看它应该属于值对像，传输的应该是DTO吧。VO应该是某个模型的子集，我这么理解！

这个主题共有 15 回复 ／ 2 页 1 2 ►
 
上一篇: 今天争论了一天的权限设计问题~请指教 下一篇: 这样一个领域模型设计究竟好不好？
 
查询本论坛 最热门帖子

热点Tag: AOP cache 缓存 DDD EJB 集群 设计模式 Hibernate IOC JiveJdon OO RBAC Seam Spring Struts

标签总列表


Jdon框架演示

JiveJdon3.0
源码下载

GoF设计模式

在线教程

社区精彩讨论




google yahoo 新浪ViVi 365Key网摘 天极网摘 CSDN网摘 添加到百度搜藏 POCO网摘 博采网摘





手机阅读 add to google add to yahoo
联系我们 | 关于我们 | RSS订阅 | 广告联系 | 网站地图
Copyright (C) 2002-2008 Jdon.com, All Rights Reserved 版权所有 上海解道计算机技术有限公司
沪ICP备05018152号 如有意见请与我们联系 Powered by JdonFramework