我们公司是从PB起家的，有非常多的数据库设计人员（他们对OOD了解比较少）。
基本上作软件的思路是：分析－>确定数据库设计->确定UI设计->开始干活。
同时，很多商业逻辑会体现在在数据库上，会有很多的数据库对象象触发器、
存储过程和函数。
现在Java项目经理遇到的难题是：项目到底需要数据库设计人员吗？
如果使用数据库设计人员，他们一定会坚持将原来的风格带到数据库设计上，而
Java的分析员给出的模型就会与数据库设计冲突很大。
那么，我们是不是根本不用数据库设计人员？根据对象分析的结果生成的DDL来
建立数据库对象？
举个例子：
某大学的选课系统，有选课业务、退选业务。我们的数据库设计人员就会给出
两张表，基本上没有什么分析抽象的过程，只是简单存储这两个业务的数据：
==============
选课表：
---------
主键
选课日期
课程编号
课程名称
课程学分
学号
姓名
性别
系别
专业
===============
退选表:
---------
主键
退选日期
课程编号
课程名称
课程学分
学号
姓名
性别
系别
专业
而Java设计人员就要求对象：
学生：
========
学号
姓名
性别
系别
专业
课程：
========
课程编号
课程名称
课程学分
选课记录：
========
学生
课程
选课日期
是否退选
退选日期
而数据库设计人员不理解java对象的设计，坚持自己的设计，甚至从java设计人员不熟悉的数据库性能
原因来驳斥java对象设计的合理性，比如：他讲，如果我要列出退选课的学生，java的设计要关联几个
表，如果有1000万学生，多慢啊，还是我的设计好，只要查询一个表，快！
那么，作为项目经理我是干脆不要数据库人员的设计呢，还是写非常复杂的DAO来实现这两者的映射？
Re:OOD需要数据库设计吗？ 发贴:charles 2003.04.18
同样的问题我们也遇到过，如够你看过我的关于我们team左设计的贴子，好像是鸡和鸡蛋的贴子。
数据库设计人员的设计又问题吧，数据太多容余了。如果学号要改或专业要改，不是很麻烦，当然DBA
多半会用个trigger + function来更新 :-)
这里不说他们设计的好坏，其实软件怎么做都可以，我相信最后多半也能做出来用。我觉得作为项目经
理应该鼓励他们提出自己的想法，如何平衡，则取决用用户和需求和开发维护的需要。
首先用户的要求通常是尽快实现商业需求，然后才是性能需求。项目开发的优先权也应该符合这个向后
次序。如果java developer觉得他们的设计可以让他们更快和容易的实现逻辑和容易维护，那应该先采
用java developer的设计，但不是说否定数据库设计人员的设计，只是现在priority不是性能。但如果
用户在测试中发现性能不能满足需要，那时就是数据库人员的用户之地了。他们需要做性能优化，甚至
是对表结构进行改动。
p.s.这些表和数据量（我猜不会大到哪里去），两种设计的数据库效率差别实在有限，应该会在几十个
毫秒，用户端的差别可能就是1秒左右。
Re:Re:OOD需要数据库设计吗？ 发贴:netwiser 2003.04.20
说到底，这是两种思想的冲突，一种是传统的Procedure平面性的设计，一种是Object-Oriented三维型
的设计，然后面临如何跨接这两种设计的尴尬，因此采用哪种方式，在于项目经理想达到什么样得目
标，以及对系统长远计划的定位。如果是想尽快实现用户的需求，那么采用数据库设计人员的设计，可
以简洁明了，快速编码，但长远来看，商业逻辑变化带来数据结构的变化而产生的修改要求将是一场恶
梦； 采用面向对象的设计，开始时层次较多，需要分析，封装的东西较多，相应的需要花费多一些时
间，但长远来看，后续的修改d对封装良好的对象所带来的冲击不是很大，至少相对而言小的多。
Re:Re:Re:OOD需要数据库设计吗？ 发贴:cloudeye 2003.04.20
Charles的回答多少出乎我的意料--我推测Charles现在更可能担任项目管理职位而不是系统分析
员。:)
这个项目是我担任项目管理职位的第三个项目，同时我也做系统分析。
说个实话，我拿到数据库表结构的时候火冒三丈，这是什么设计！简直就是把需求中的业务表单抄下
来！要把我的对象持久到这些表结构上简直要我的老命！
看看我们的“资深PB开发人员”发达的胸肌和准备和我一争到底雄心壮志的样子，再想想部门经理的教
诲“你已经不是一个干体力活的程序员了，当PM要学一些太极拳”，还是把火给压了下去。sigh.. :(
我想我还未真正从一个开发者的角色调整到PM的角色来思考吧，遇到自己认为不合理的设计简直就如梗
在喉很难接受....如果采取这样的数据库设计，做DAO要花费很大的工夫。
我曾经和我们的总工谈到这个问题，陈列OO分析和设计的好处...可惜，总工PB+ORACLE出身，Oracle上
功力深厚，看到表结构的评论就是“还可以啊，简单明了，不行的话写个存储过程或触发器了”。
sigh..看来要上下同心还需要时间..现在这个阶段只好痛苦一番了！
Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:netwiser 2003.04.21
〉再想想部门经理的教诲“你已经不是一个干体力活的程序员了，当PM要学一些太极拳”
看到这里，确实心里暗笑，sign，老兄，您面临的压力实在太大了，从总工，手下设计人员到你的直接
老板，都会给你非常大的阻力。尤其是你的直接老板，对软件开发的理解偏差很大，难保他在你后续的
工作中会给出错误的意见和指令。
在深入说一句，Charles和你总工的话都是有道理的，上面我已经提到数据库设计是一种二维式的设
计，因此，不论你如何优化，始综无法达到对象设计的要求（除非您使用了对象数据库）。一个Flat的
数据结构多少会影响性能，但不是非常的大。 我想，这也是对你的一种挑战，看看如何优化你的DAO
Design，让它在这样的Schema上达到你想要得效果。
Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:netwiser 2003.04.21
这里有个Trick，Design时设计两个Data Object，一个是Full Load的，就是包含了你所需要的一个
Domain中的所有attributes，另外再提炼一个ligthweight的Data Object，是full load 的子集，包含
经常使用的domain 中的attributes，再仔细定义JDBC Connection的Isolation Level，把设计中的可
能性的缺陷降到可把握的程度。
Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.21
坦白地说，我觉得你们数据库设计人员做法比较可取，当然前提是在大表的情况下，使用一定的冗
余，来提高系统的性能和编程的简易性。此外考虑程序的可移植性，数据库的设计也应该简洁，避免
复杂的关联，提高可移植性。我也是3年前从pb+oracle转过来，现在很多java从业人员数据库方便的
功底太差，很多东西想当然，好好补补数据库的知识还是有必要。oo只是一个幌子，用不着到处吓
人。PB也是种基于对象的语言，我就见过厉害的PB程序员写出的东西，都是OO的概念，比大部分JAVA
程序员写得好多了，虽然他们自己也不太明白。用JAVA不等于你再做OOA/D/P.此外不同程序员写出的
代码，效率差10多倍我也看过。比如3年前我们做的应用，用ejb做出的所谓先进的oo垃圾，速度比以
前的应用慢了几十倍。
oo的设计从对象出发，寻找对象，定义对象，最后还要实现对象和关系数据的映射，但这并不意味着
Domain model的domain对象必须和 数据库中的表的有一一对应的关系，通过一个比较良好的o-r
mapping设计可以平滑的修补两者之间的差异，不存在不可调和的问题。。如果你们的项目是大规模的
关键应用，有经验的数据库设计人员坐表结构的设计必不可少。如果OO分析人员出来的东西有你所谓
的重大冲突，又不可调和的话，不客气地说，我建议你把那些所谓的OO高手（我看都是些书呆子，要
不是就是牛皮子）都开了吧，至少保证这个系统可以跑，最后你再把你自己开了，谁让你是个PM,连这
个都定不了。
回应这个帖子
Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.21
有什么好火冒的？就这个就要你老命的话，我觉得你开发能力也太一般。至少对你这个退课的例子来
说，我不认为做dao回花很大的功夫，至少对我来说，这两种设计在dao层花的EFFORT差不多。如果你
设计的好的话，你甚至完全可以把那些SQL都交给DATABASE的老手去写.
你再仔细考虑一下EAI的设计，那里面大量的机会都是和传统数据的联接，那你不是更要跳楼？如果你
的数据存储必须是用其他方式实现，你是不是还非的让人家给你弄出一个现成的OO什么来？
即便设计是不合理的，也可以协商沟通怎么会如梗在喉？
别介意，我就是随便说说。
Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.21
还是这位老大说的到点子上。当年我刚从学校出来，就是被老师和教科书害了，弄出一堆理论性的垃
圾。
Re:OOD需要数据库设计吗？ 发贴:frenzieddragon 2003.04.21
我的看法：
你们数据库人员设计出来的结构性能是高，但是一旦添加或者删除学生的属性，你们要改的地方肯定会
比java设计人员设计出的还多（因为学生的属性在多个表中重复，如果你们的系统不只这两个表有学生
的数据，那就更恐怖了），还容易漏掉，难以维护。除非是性能上有缺陷，否则我是不会采用你们数据
库设计人员的结构的，都这么设计了我还要表间的关联干啥。
Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.21
不考虑性能当然无所谓，如果真是1千万以上的纪录，不这样做可能还真不行。我估计他这个里面
应该还有一张完整的学员信息表，在退课/选课表里的学员信息只是基本信息，对该表的更新的时候用
trigger或者在DAO层同时更新退课和选课表。
我听说过最牛X的一个设计就是只有一张巨大的主表，然后在上面狂建不同的视图来实现。
其实么，什么样的性能好，就让DBA老手去做好了，只要能隐射成我要的对象，我才不管他怎么实现
的。
Re:Re:Re:OOD需要数据库设计吗？ 发贴:steffyan 2003.04.22
首先
这个业务就在乱说了，什么学校有1千万以上的纪录？做项目不能脱离自己的项目业务去想过多的不存
在的东西
完成项目优先考虑自己的资源、进度、功能
具体的实现你也要明白自己为什么要用java这种语言，还有以后的维护升级工作
采用OO的设计思路也许是项目组本身的一个学习、也可能是公司的要求，但是，作为pm的你却必须要清
楚什么可以要，什么可以不要，取舍的问题也是你安排工作进度的来源之一噢
ps:今天在google上查点东西，结果看到了这个对话，觉得有意思，注册来说说
Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.22
如果按现在巨牛的高校来算。 5万左右的学生，每学年2学期，每学期可选10门课。一年就是100万条
记录。1千万夸张，几百万还是有吧，据我所知，某些高校现在都是网上选课，而且一般都是集中在那
么几天，我有个朋友就不得不半夜里爬起来给他妹妹选课，因为白天连不上。如果是这类型应用，一
开始就考虑性能需求是非常必要的。。不过我觉得他应该是举列说明而已，不应该是真实的业务。
其实我只是比较反感所谓用了java就是oo设计的说法，因为以前公司那些不知天高地厚的所谓新贵老
是这样打击老程序员，而实际我认为他们只知道一些皮毛而已。如果数据库设计遵守3范式，就能达到
楼主所谓的合理设计，这个东西和oo无关，搂主可以去补补课。而我工作以后才发现，如果严格遵守
三范式来设计数据库，在有些应用，尤其是大数据量的应用里面是自找死路。既然有经验的总工都认
为有道理，我觉得数据库的设计应该有可取之处，和有经验的数据库开发人员作适当的沟通和协商就
应该能够很好地解决问题，一看人家的设计就火毛三丈，一点道理都没有，至少也要尊重老程序员
么。我曾经和一个老程序员谈过他的数据库后台的设计，结果发现他大量使用了现在JAVA世界里广泛
称道的设计模式的内容，比如FRONT CONTROL, FACADE之类，而他自己本身对oo/设计模式以无所知。
可见所谓的oo/procedure本身只是一个幌子，别把自己太当回事。
作为系分，考虑系统架构应该从多个角度去看，不要想当然，涉及到自己不熟悉的地方，更应该放下
架子多请教一下有经验的人,让最熟悉的人去做他最熟悉的事就好了。因为性能问题，我们曾经有不得
不把ejb做成的应用最后全部移植成存储过程来实现的惨痛教训。
随便说说，我也只是一个菜鸟，很菜菜的那种
Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:cloudeye 2003.04.23
当然，举的例子并不是真正的业务，在这个项目里，极端情况下会有
数百万条的记录。
我发现finbackplus可能太过敏感误解了我的真正意思，
"因为以前公司那些不知天高地厚的所谓新贵老是这样打击老程序员"，新
人有不断学习的动力，但是可能也会不懂得给老程序员留面子。但是我相信
“打击”是谈不上的。这个观点于老程序员自己来讲是不好的，
如果我们的数据库设计人员抱这个观点来的话，我会争取换一个人来做设计。
不管如何有经验如果在一个项目里不思进取怨天尤人只能对项目起反作用。
我觉得，面向对象确实有很多不同于传统开发方法的特性，对数据库设计的要求
也会和原来基于数据库的开发大有不同，不管资格多么老的程序员，应该认识到
这些差异努力再学习，适应新的的开发方式。论资排辈的思想就失去进步的动力，
也会给项目带来负作用。
“oo/procedure本身只是一个幌子，别把自己太当回事。 ”这句话确实不应该是
一个项目组成员所应该说的话。第一句话体现了对OO的无知和排斥，第二句话可以
看出作项目的不正确心态，更进一步，对人不对事，这不仅是作项目，也是作事的
大忌讳。
"尊重老程序员 "这是应该的，不仅要尊重老程序员，还要尊重新程序员，尊重所有
人，看得出来findbackplus是很懂礼貌的，但是，在技术问题上，不能窝窝囊囊，
你认为不对的，就要提出自己的看法。
项目组内有一个新来的毕业生，对solaris很熟悉，我有一段很常跑到他位置上问
问题(我一直用windows，但系统会在solaris上部署)；但是在概要设计的评审会上，
我们总工的观点我认为不对，也一点没有放松，只要认为正确，就要坚持观点。技术上
没有什么资辈可言，只有懂与不懂。
还是来说说正题，现在暂时我是这样来处理的：
首先项目组内进行概要设计的评审，我们的数据库设计人员也认同了系统设计。
接下来，我将DAO设计的任务分配给项目的数据库设计人员(通过项目逐渐熟悉学习java
并从CS转向BS开发，这是公司也是数据库开发人员所希望的)，他们基本可以胜任DAO的
设计工作，而且因为熟悉数据库会写得不错。
现在看来，效果还不错，在DAO设计过程中体现出来的问题甚至导致他们提出数据库结构
的调整要求。
大家的讨论给我很多启发，也更认真去考虑这个问题，从项目管理角度和技术角度。
Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.23
坦白地说我不认为你对OO真的精通，对象技术本身就是从传统的过程发展来的，在传统的过程开发里
面都有很多体现对象技术精髓的列子，即便是用pb，甚至c的程序里面，你都可以找到大量好手实现的
封装，重用，甚至组件化的例子。 你可以到陶清论坛，看看那些顶尖的pb好手，对对象技术理解是不
是比你更强？ 我在有些pb老手的程序里看到的重用和封装的程度，我现在也做不到这么好，那都是他
们多年经验的积累。
"第一句话体现了对OO的无知和排斥，第二句话可以看出作项目的不正确心态", 我只能说你真的比较
无知,至少比我无知。对真正的传统高手来说，对象技术只是一层纸而已，捅破了，就通了。对象技术
的大师和理论家无一不是从过程开发里走出来的。对象技术实际是传统过程开发里面一些很好实践的
总结。拿现在又开始热起来的COP/AOP来说，我是否可以说我用这些技术作开发，就可以贬低OO的价
值？就可以认为OO是一种要淘汰的东西？我是否可以跑到一个OO的大师面前，跟他说，现在是COP/AOP
的时代了，你过时了，你需要认真学习，你需要向我学习? 保持平等的心态，不要太把自己当会事
心理上的优越感，只会是暂时的。我手里就有现成例子，没什么经验的新手，3个月以后比那些自己鼓
吹2，3年j2ee开发经验的所谓老手强的多。3个月前是他开口闭口教育别人，3个月后是别人反过来教
育他。别太把自己当回事，在你成文高手之前，至于之后，就更不要把自己当回事了。
我曾经和不少老程序员谈OO，结果发现跟他们的沟通远比和一些所谓的新贵容易得多，至少他们不会
整天把OO挂在嘴上，做出一些不伦不类的东西。经验是一种很宝贵的财富，不是靠所谓的新技术短期
内能积累的。一个会在应用中，创造，并实践设计模式的老程序员，远比看了dp就在那卖的你所谓的
熟悉对象技术的程序员强的多，只要给予适当的引导，你就能看到效果。
一个过程开发的好手，成为一个OO开发好手的几率，要比一个oo新手，或者一个所谓的oo好手，成为
真正好手的几率高的多。这几年我看过太多我们所谓的OO高手写出来的惨不忍睹的东西，用JAVA不等
于你是OO的，用C/PB/PL SQL也不等于你就是非OO,开发技术的发展，无非就是为了提高开发的效率，
经可能的提高代码的重用性，可维护性，扩展性。很多方面，不管使用哪一种技术，很多东西本质上
都是相同的。oo不oo并重要，至少我认识的高手，从来不把oo挂在嘴上。至于所谓打击，只是一种说
法吧，坦白的说，好的程序员绝对不会怨天尤人，只有给他们一点点信心和时间，就可以做好。在我
团队里，我不会允许谁对老手说，你的那些都过时了的话。
作为一个所谓的OO的好手，如果不正视这些本质的东西，肆意否定一些东西，我觉得你是扼杀老程序
员的创造性。一个java好手，肯定可以成为一个c#好手，同样，一个PB/ORACLE的好手，肯定也可以成
为一个java的好手，编程的本质是相通的。
技术上没有资辈可言，但是换一个角度看问题，你会发现自己未必是对的。如果你能看到问题的本
质，你就有更好的解决办法。给予他们适当的引导，几个月以后，你会发现他们有些人会做的比你还
要好，这是我的经验。我不尊重老程序员，我只尊重优秀的老程序员，不管他是写什么的。
我是一个很菜菜的菜鸟，对前途很困惑的菜鸟，做菜鸟的唯一好处，就是可以胡说八道，又不会丢面
子。
Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:frenzieddragon 2003.04.23
"对象技术本身就是从传统的过程发展来的"这句话好像是错的，据我所知，面对对象技术和面向过程的
技术基本上是同时代产生的技术，只不过最近10年才被广泛应用而已。
Re:Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.23
呵呵，被抓到尾巴了，俺不是学究，说得很不准确哦，不要砸我，我是菜鸟。
应该是有很大联系吧， 基于结构的过程语言出现更早一些，当时计算机硬件的条件决定了对象技术不
可能实施，所以对象技术是理论的，缺乏实用性，记得以前的教科书讲过函数的出现是软件开发式一
个milestone.对象技术的最早出现在50年代的lisp,和60年代的simula都有体现，真正投用实用是在80
年代以后，很多理论都是对在传统的过程开发去的经验上作的完善和修改。而过程语言也不断演化，
逐渐加入对象的特征，甚至演变成真正的对象语言。比如c->object c, pascal -> object pascal.80
年代后期,90年代出现的快速开发语言基本上都引入了一定对象特征，所以叫做object based德，比如
vb, pb.对象设计里面的重要概念封装，重用，抽象，都能在传统的过程语言里面找到对应的东西。
我见过的一些成精的老家伙写的东西，不写重复的代码-〉公用函数-〉函数库， 提高代码的可维护性
何易修改行-〉功能分解，简单化，专一化-> 对象职责？ 数据封装-〉结构. 很多东西都是可以相通
的。如果用的是pb/pl-sql就更多了，因为语言本身糅入不少对象的特性，那就用得更好了。 我见过
人家用PL-SQL实现的FRONT CONTROL, 和FACADE,还有近似的MEMENTO ， COMMAND
用传统的非对象技术开发走的是对象-〉过程，结构这样的路子，对象的概念还是有的，只是实现不同
或则限制于语言特性有些东西难以实现罢了，所以说作PB/ORACLE就不懂对象技术，我说那是胡扯，用
了JAVA就高人一等，动不动就说别人无知，那更是胡扯。我前面就说，搂主的表结构只是要不要遵守3
范式的问题，这要结合实际应用的情况。用不着提到那么高的高度，什么对象开发和传统开发的矛
盾。面向对象只是一种解决问题的思路，和语言之间没有必然的等号。我看过有家NX德公司的JAVA
CODE，一个类里面有几万行代码，一个方法有几千行代码，大量的CTR-C/V，这就是面向对象？
我语文不好，有些地方说得不明白，大致精神就是这样了，要扔砖头的继续扔。
Re:Re:Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:liu_ruyan 2003.04.24
俺菜鸟也来凑个热闹！
finbackplus 的观点：oo并不就代表着高人一等，好的过程高手照样可以写出很优美的程序！
我的观点： 如果懂得oo的话应该是比较容易达到上面的一般只有高手才能达到的境地！
另为楼主的建议： 如果为java来开发的话，可以考虑下
hibernate 和 jdo这两个东东，，应该会对你很有帮助的！
Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:johnsonqu 2003.04.24
确实如此啊！
做J2EE开发的，有时间的话，还是去看看EXPERT ONE-TO-ONE J2EE DESIGN AND DEVELOPMENT,里面有很
多中肯的意见。
另外，对于很多使用RDMS(目前的大部分情况)项目来说，采用ORM的工具或者JDO确实是比较理想的解决
方案。
Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:steffyan 2003.04.30
转一篇，希望对大家有所帮助
对软件工程的一点看法(之三)--关于OO
空军一号 发表于 2003-4-9 1:13:38 软件工程 ←返回版面 [快速返回]
在网上看到的一些帖子里，很多人把OO和软件工程不加区分，实际上OO和软件工程是两回事，下面是一
些个人观点。
OO是一种软件分析、设计方法，或者说是思想。C++, Object Pascal, java等等高级语言，是将OO思想
用代码进行表述的手段。而软件工程则是用工程学的手段，对软件的全生命周期，包括需求、设计、编
码、测试、维护等各个阶段进行量化管理。Rose是一种软件工程的辅助工具，UML则侧重于在软件需求
与设计阶段，提供一套完整的，以OO的方式进行描述、交流的形式化语言符号。
从这个意义上来说，能够用OO进行思考，远比能够使用OO工具来的重要。实际上，用非OO的高级语言，
也能实现OO的设计。此外，我还想强调一点，OO与传统的结构化设计，或者面向流程的设计并不矛盾。
他们之间的区别，主要在于解决问题的方式或次序不同。正确的使用OO的方法，能够得到更好的系统结
构和可重用性，并且降低编码工作量。与面向过程的方法不同，OO更加强调设计体系的合理性。不合理
的OO设计往往比不合理的面向过程设计带来更多的负面影响。
但是OO也不是万能的，现在流行的编程语言往往是OO与面向过程的混合体。如C++和Object Pacal。这
主要的因为纯OO的编程语言，往往不能产生比较高效的代码。
即便是系统设计采用了OO，在编码的时候，对象内部仍然是面向过程的。因此，面向过程仍然是OO的基
础，做不好面向过程的代码，OO也是空中楼阁。
C++作为流行的OO工具，也有一定的缺陷。以C++为基础的类库，虽然功能强大，但是也带来学习周期长
的问题。要想掌握一个C++类库，如MFC，不深入代码，很难发挥出类库的潜力，写出好的程序。
现在我们很多的程序员，没有深刻的理解计算机体系结构，不了解编译程序的工作原理，不能灵活的运
用数据结构，更不清楚操作系统的工作原理。实际上来说，这种水平去做面向过程的Coding都不合格，
怎么可能去很好的OO呢？
我说这些话的意思是，尽管现在有了好的工具，好的教科书，并不能解决目前普遍存在的程序员能力的
问题。在实际运用OO之前，起码要做到两条：
1。Thinking in computer
2. Thinking in OO
JDO方面的问题 发贴:netwiser 2003.05.01
>另为楼主的建议： 如果为java来开发的话，可以考虑下
> hibernate 和 jdo这两个东东，，应该会对你很有帮助的！
想请问一下，在JDO的Cross Domain Transaction 方面如何处理？
我最近用JDO写了一个Persistence Framework，目的是把 Persistence Manager,
PersistenceManagerImpl进行封装，但在此过程中遇到不少麻烦。目前JDO 1.0Spec规定： 每个
Persistence Capable Object associates with a Persistence Manager，而每个 Transaction
associcates with a Persistence Manager instance，而且，在没有Transaction Active的情况下，
是不能对Persistence Capable Object进行 Modify，除非 explict define the
NonTransactionalWrite to TRUE。问题出在这里，一个Transaction 拖的很长，但还不是很麻烦，我
可以在Update开始前，Explict call 我的PM的preUpdate，启动一个Transaction，而后维护一个
Waiting Thread Pool，确保每次只有一个Thread Access this Transaction instance， update完
后，explict call postupdate，commit and notify the waiting thread。基于如此，我只能为每个
Domain associates一个 Persistence Manager Implementation，否则Transcation 跨度很长，但是遇
上cross domain而且需要一个Transcation中提交的scenario，就很难处理， e.g. Domain product拥
有一个PersistenceManagerImpl， Domain CreditCard也拥有一个PersistenceManagerImpl 各自负责
处理自身的Domain persistence requires，但我当我place order时，我要把OrderLineItem保存，同
时也要把CreditCard扣帐，而这时至少有两个完全不同的Flat Transaction，即我不能再一个
Transcation中embedded另一个Transcation。 我曾试想把Transcation 独立出来为一个Transcation
Manager，但又无法剥离Persistence Capable Object 与Persistence Manager的紧密耦合关系。
不知道是小的愚昧，未能悟透JDO的奥秘，抑或是JDO 现在的实现问题太多？ 望各位大虾有以教我！！
Re:JDO方面的问题 发贴:cinc 2003.06.10
没用过 jdo ，但用过其他两个 o/r mapping 的工具
以前在使用 castor 的时候也遇到了这个 cross domain transaction 的问题
castor 解决的也不是很好，在 一个 transaction 里获得的对象，送到 ui layer 更新后
就没法在新的 transaction 里把这个对象更新到数据库了
听说 castor 支持一个 long transaction 的冬冬，没仔细研究
用了一个变通的办法，把 update() 方法改成了下面的样子，把 ui 传过来的 对象再赋值到
persistence layer 里的对象。
AccountDAO.updateAccount(Account account){
Database db = getDatabase();
db.begin();
dbAccount = ... // get account from db
// set dbAccount with new values
dbAccount.setName( account.getName());
dbAccount.setSex( account.getSex());
db.commit();
db.close();
}
但如果遇到 nested class 就晕了。
最近在研究 hibernate，感觉蛮不错的
hibernate 使用两种方法来实现 cross domain transaction，真正实现 presentation layer 和
business layer 的分离：
1.Updating objects saved or loaded in a previous session
多用于 3 层环境
好像里面使用了 versioning 来 manipulates the state of transient instances
originally loaded in another Session （在db 的那个表里多了一列 version）
The <version> element is optional and indicates that the table contains versioned
data. This is particularly useful if you plan to use long transactions
2.Session disconnection
多用于 2 层 web 环境
同一个 session，从 db 获得对象后，先 disconnect()，并把 session 存放到 httpsession 里
然后让用户修改这个对象，提交后，再从 httpsession 中取得这个 session ，reconnect()，把
对象存放到数据库
这里的 session 相当于一个 transaction
下面摘了些文档：
1.In a three tiered architecture, consider using saveOrUpdate().
When using a servlet / session bean architecture, you could pass persistent objects
loaded in the session bean to and from the servlet / JSP layer. Use a new session to
service each request. Use Session.update() or Session.saveOrUpdate() to update the
persistent state of an object.
Usually update() or saveOrUpdate() are used in the following scenario:
the application loads an object in the first session
the object is passed up to the UI tier
some modifications are made to the object
the object is passed back down to the business logic tier
the application persists these modifications by calling update() in a second session
saveOrUpdate() does the following:
if the object is already persistent in this session, do nothing
if the object has no identifier property, save() it
if the object's identifier matches the criteria specified by unsaved-value, save() it
if another object associated with the session has the same identifier, throw an exception
2.In a two tiered architecture, consider using session disconnection.
When using a servlet only, you may reuse the same session for multiple client requests.
Just remember to disconnect the session before returning control to the client.
Session disconnection
The first approach described above is to maintain a single Session for a whole business
process thats spans user think time. (For example, a servlet might keep a Session in the
user's HttpSession.) For performance reasons you should
commit the Transaction (or JDBC connection) and then
disconnect the Session from the JDBC connection
before waiting for user activity. The method Session.disconnect() will disconnect the
session from the JDBC connection and return the connection to the pool (unless you
provided the connection).
Session.reconnect() obtains a new connection (or you may supply one) and restarts the
session. After reconnection, to force a version check on data you aren't updating, you
may call Session.lock() on any objects that might have been updated by another
transaction. You don't need to lock any data that you are updating.
具体可以看看 hibernate 2.0 的 Hibernate2 Reference Documentation
章节：
4.1.7. version
7.5. Updating objects saved or loaded in a previous session
13.3. Optimistic Locking / Versioning
13.4. Session disconnection
15. Best Practices
Re:Re:JDO方面的问题 发贴:finbackplus 2003.06.11
使用assigned id
同一个domain obj，save 了2次，第2次肯定出错，问题是出错了以后。再作load就把表锁死了。
对session做disconnect/reconnect，才可以。你又没有碰到。save出错有座rollback();
db 8.1 ee/ hibernat 2.0
Re:Re:Re:JDO方面的问题 发贴:cinc 2003.06.11
session 做 disconnect/reconnect 只是一种方法
还有另一种方法是 Updating objects saved or loaded in a previous session
不要用 save()，save 只能用来创建对象到数据库
如果不能肯定是创建，还是更新，用 SaveOrUpdate()，下面是例子：
public Company updateCompany(Company company) throws HibernateException {
Session s = HibernateSessionFactory.openSession();
Transaction tx = null;
try{
tx = s.beginTransaction();
s.saveOrUpdate( company );
tx.commit();
}catch(HibernateException he){
if ( tx!=null ){
tx.rollback();
}
throw he;
}finally{
s.close();
}
return company;
}
hibernate 会根据 unsaved-value 和 cascade 的设置判断是 save 还是 update
：）
Re:OOD需要数据库设计吗？ 发贴:pilgram 2003.10.30
不谈oo
1.这个例子，如果你的业务只有两种，用数据库设计人员的解决方案
2.如果要包含修改学生信息，其他学生考试成绩信息等新的业务，你就要按照java的解决方案
其实java的解决方案是一种更接近3nf（我没有仔细看），象楼上的说的，适合添加，删除，
修改信息。便于扩展维护
数据库设计人员可以创建两个view来 将java类型表格转换成任务需要的退课表、选课表
这里其实不是oo和数据库设计的矛盾。
Re:Re:OOD需要数据库设计吗？ 发贴:hezhihuang 2003.10.31
看到有人在为OO和DB争执的这么厉害,而且还罗列出如此之多的证据名言什么的,感觉到这个世界真是
他大了,学海无涯啊!
不过这种争执就类似于使用哪种编程语言的争执,说到最后还是为了使项目能够完成得更好,更成功.这
才是最终的追求目标啊!
看得出cloudeye和finbackplus两位老兄都是热血青年,慷慨激昂啊! 不过只要能让项目成功,又何必过
于在意是不是OOD/OOP呢? smalltalk是最完美的面向对象语言,但最成功的面向对象语言还是C++/Java
啊!
既然手下有那么多的PB高手, 又何必非要坚持让他们使用完全不熟悉的OO呢? cloudeye你是PM,也是系
分,但如果你设计出来的东西别人不理解或者不容易理解,那即使你设计得如何完美,也只是一个虚幻的
空中楼阁而已! 另外,我想衡量一个PM的最重要一条不是你用了什么技术,而是你这个项目的成败
啊! -------- 如果有一个输出Hello, World!的项目的话, 我倒是宁可使用Basic,简单的
print 'Hello, World!'了事, 这里感觉连C的main(...)都很烦琐,又何况java的class HelloWorld呢?
无论是产品和项目,都首先必须保证项目的成功;而项目的成功,又离不开"沟通"二字啊!
Re:OOD需要数据库设计吗？ 发贴:BirdGu 2003.11.04
就事论事的说，这不是OO和Relational的问题，这是要不要遵循第三范式的问题。更Java, PB都没关
系。
基本上作软件的思路是：分析－>确定数据库设计->确定UI设计->开始干活。
同时，很多商业逻辑会体现在在数据库上，会有很多的数据库对象象触发器、
存储过程和函数。
现在Java项目经理遇到的难题是：项目到底需要数据库设计人员吗？
如果使用数据库设计人员，他们一定会坚持将原来的风格带到数据库设计上，而
Java的分析员给出的模型就会与数据库设计冲突很大。
那么，我们是不是根本不用数据库设计人员？根据对象分析的结果生成的DDL来
建立数据库对象？
举个例子：
某大学的选课系统，有选课业务、退选业务。我们的数据库设计人员就会给出
两张表，基本上没有什么分析抽象的过程，只是简单存储这两个业务的数据：
==============
选课表：
---------
主键
选课日期
课程编号
课程名称
课程学分
学号
姓名
性别
系别
专业
===============
退选表:
---------
主键
退选日期
课程编号
课程名称
课程学分
学号
姓名
性别
系别
专业
而Java设计人员就要求对象：
学生：
========
学号
姓名
性别
系别
专业
课程：
========
课程编号
课程名称
课程学分
选课记录：
========
学生
课程
选课日期
是否退选
退选日期
而数据库设计人员不理解java对象的设计，坚持自己的设计，甚至从java设计人员不熟悉的数据库性能
原因来驳斥java对象设计的合理性，比如：他讲，如果我要列出退选课的学生，java的设计要关联几个
表，如果有1000万学生，多慢啊，还是我的设计好，只要查询一个表，快！
那么，作为项目经理我是干脆不要数据库人员的设计呢，还是写非常复杂的DAO来实现这两者的映射？
Re:OOD需要数据库设计吗？ 发贴:charles 2003.04.18
同样的问题我们也遇到过，如够你看过我的关于我们team左设计的贴子，好像是鸡和鸡蛋的贴子。
数据库设计人员的设计又问题吧，数据太多容余了。如果学号要改或专业要改，不是很麻烦，当然DBA
多半会用个trigger + function来更新 :-)
这里不说他们设计的好坏，其实软件怎么做都可以，我相信最后多半也能做出来用。我觉得作为项目经
理应该鼓励他们提出自己的想法，如何平衡，则取决用用户和需求和开发维护的需要。
首先用户的要求通常是尽快实现商业需求，然后才是性能需求。项目开发的优先权也应该符合这个向后
次序。如果java developer觉得他们的设计可以让他们更快和容易的实现逻辑和容易维护，那应该先采
用java developer的设计，但不是说否定数据库设计人员的设计，只是现在priority不是性能。但如果
用户在测试中发现性能不能满足需要，那时就是数据库人员的用户之地了。他们需要做性能优化，甚至
是对表结构进行改动。
p.s.这些表和数据量（我猜不会大到哪里去），两种设计的数据库效率差别实在有限，应该会在几十个
毫秒，用户端的差别可能就是1秒左右。
Re:Re:OOD需要数据库设计吗？ 发贴:netwiser 2003.04.20
说到底，这是两种思想的冲突，一种是传统的Procedure平面性的设计，一种是Object-Oriented三维型
的设计，然后面临如何跨接这两种设计的尴尬，因此采用哪种方式，在于项目经理想达到什么样得目
标，以及对系统长远计划的定位。如果是想尽快实现用户的需求，那么采用数据库设计人员的设计，可
以简洁明了，快速编码，但长远来看，商业逻辑变化带来数据结构的变化而产生的修改要求将是一场恶
梦； 采用面向对象的设计，开始时层次较多，需要分析，封装的东西较多，相应的需要花费多一些时
间，但长远来看，后续的修改d对封装良好的对象所带来的冲击不是很大，至少相对而言小的多。
Re:Re:Re:OOD需要数据库设计吗？ 发贴:cloudeye 2003.04.20
Charles的回答多少出乎我的意料--我推测Charles现在更可能担任项目管理职位而不是系统分析
员。:)
这个项目是我担任项目管理职位的第三个项目，同时我也做系统分析。
说个实话，我拿到数据库表结构的时候火冒三丈，这是什么设计！简直就是把需求中的业务表单抄下
来！要把我的对象持久到这些表结构上简直要我的老命！
看看我们的“资深PB开发人员”发达的胸肌和准备和我一争到底雄心壮志的样子，再想想部门经理的教
诲“你已经不是一个干体力活的程序员了，当PM要学一些太极拳”，还是把火给压了下去。sigh.. :(
我想我还未真正从一个开发者的角色调整到PM的角色来思考吧，遇到自己认为不合理的设计简直就如梗
在喉很难接受....如果采取这样的数据库设计，做DAO要花费很大的工夫。
我曾经和我们的总工谈到这个问题，陈列OO分析和设计的好处...可惜，总工PB+ORACLE出身，Oracle上
功力深厚，看到表结构的评论就是“还可以啊，简单明了，不行的话写个存储过程或触发器了”。
sigh..看来要上下同心还需要时间..现在这个阶段只好痛苦一番了！
Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:netwiser 2003.04.21
〉再想想部门经理的教诲“你已经不是一个干体力活的程序员了，当PM要学一些太极拳”
看到这里，确实心里暗笑，sign，老兄，您面临的压力实在太大了，从总工，手下设计人员到你的直接
老板，都会给你非常大的阻力。尤其是你的直接老板，对软件开发的理解偏差很大，难保他在你后续的
工作中会给出错误的意见和指令。
在深入说一句，Charles和你总工的话都是有道理的，上面我已经提到数据库设计是一种二维式的设
计，因此，不论你如何优化，始综无法达到对象设计的要求（除非您使用了对象数据库）。一个Flat的
数据结构多少会影响性能，但不是非常的大。 我想，这也是对你的一种挑战，看看如何优化你的DAO
Design，让它在这样的Schema上达到你想要得效果。
Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:netwiser 2003.04.21
这里有个Trick，Design时设计两个Data Object，一个是Full Load的，就是包含了你所需要的一个
Domain中的所有attributes，另外再提炼一个ligthweight的Data Object，是full load 的子集，包含
经常使用的domain 中的attributes，再仔细定义JDBC Connection的Isolation Level，把设计中的可
能性的缺陷降到可把握的程度。
Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.21
坦白地说，我觉得你们数据库设计人员做法比较可取，当然前提是在大表的情况下，使用一定的冗
余，来提高系统的性能和编程的简易性。此外考虑程序的可移植性，数据库的设计也应该简洁，避免
复杂的关联，提高可移植性。我也是3年前从pb+oracle转过来，现在很多java从业人员数据库方便的
功底太差，很多东西想当然，好好补补数据库的知识还是有必要。oo只是一个幌子，用不着到处吓
人。PB也是种基于对象的语言，我就见过厉害的PB程序员写出的东西，都是OO的概念，比大部分JAVA
程序员写得好多了，虽然他们自己也不太明白。用JAVA不等于你再做OOA/D/P.此外不同程序员写出的
代码，效率差10多倍我也看过。比如3年前我们做的应用，用ejb做出的所谓先进的oo垃圾，速度比以
前的应用慢了几十倍。
oo的设计从对象出发，寻找对象，定义对象，最后还要实现对象和关系数据的映射，但这并不意味着
Domain model的domain对象必须和 数据库中的表的有一一对应的关系，通过一个比较良好的o-r
mapping设计可以平滑的修补两者之间的差异，不存在不可调和的问题。。如果你们的项目是大规模的
关键应用，有经验的数据库设计人员坐表结构的设计必不可少。如果OO分析人员出来的东西有你所谓
的重大冲突，又不可调和的话，不客气地说，我建议你把那些所谓的OO高手（我看都是些书呆子，要
不是就是牛皮子）都开了吧，至少保证这个系统可以跑，最后你再把你自己开了，谁让你是个PM,连这
个都定不了。
回应这个帖子
Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.21
有什么好火冒的？就这个就要你老命的话，我觉得你开发能力也太一般。至少对你这个退课的例子来
说，我不认为做dao回花很大的功夫，至少对我来说，这两种设计在dao层花的EFFORT差不多。如果你
设计的好的话，你甚至完全可以把那些SQL都交给DATABASE的老手去写.
你再仔细考虑一下EAI的设计，那里面大量的机会都是和传统数据的联接，那你不是更要跳楼？如果你
的数据存储必须是用其他方式实现，你是不是还非的让人家给你弄出一个现成的OO什么来？
即便设计是不合理的，也可以协商沟通怎么会如梗在喉？
别介意，我就是随便说说。
Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.21
还是这位老大说的到点子上。当年我刚从学校出来，就是被老师和教科书害了，弄出一堆理论性的垃
圾。
Re:OOD需要数据库设计吗？ 发贴:frenzieddragon 2003.04.21
我的看法：
你们数据库人员设计出来的结构性能是高，但是一旦添加或者删除学生的属性，你们要改的地方肯定会
比java设计人员设计出的还多（因为学生的属性在多个表中重复，如果你们的系统不只这两个表有学生
的数据，那就更恐怖了），还容易漏掉，难以维护。除非是性能上有缺陷，否则我是不会采用你们数据
库设计人员的结构的，都这么设计了我还要表间的关联干啥。
Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.21
不考虑性能当然无所谓，如果真是1千万以上的纪录，不这样做可能还真不行。我估计他这个里面
应该还有一张完整的学员信息表，在退课/选课表里的学员信息只是基本信息，对该表的更新的时候用
trigger或者在DAO层同时更新退课和选课表。
我听说过最牛X的一个设计就是只有一张巨大的主表，然后在上面狂建不同的视图来实现。
其实么，什么样的性能好，就让DBA老手去做好了，只要能隐射成我要的对象，我才不管他怎么实现
的。
Re:Re:Re:OOD需要数据库设计吗？ 发贴:steffyan 2003.04.22
首先
这个业务就在乱说了，什么学校有1千万以上的纪录？做项目不能脱离自己的项目业务去想过多的不存
在的东西
完成项目优先考虑自己的资源、进度、功能
具体的实现你也要明白自己为什么要用java这种语言，还有以后的维护升级工作
采用OO的设计思路也许是项目组本身的一个学习、也可能是公司的要求，但是，作为pm的你却必须要清
楚什么可以要，什么可以不要，取舍的问题也是你安排工作进度的来源之一噢
ps:今天在google上查点东西，结果看到了这个对话，觉得有意思，注册来说说
Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.22
如果按现在巨牛的高校来算。 5万左右的学生，每学年2学期，每学期可选10门课。一年就是100万条
记录。1千万夸张，几百万还是有吧，据我所知，某些高校现在都是网上选课，而且一般都是集中在那
么几天，我有个朋友就不得不半夜里爬起来给他妹妹选课，因为白天连不上。如果是这类型应用，一
开始就考虑性能需求是非常必要的。。不过我觉得他应该是举列说明而已，不应该是真实的业务。
其实我只是比较反感所谓用了java就是oo设计的说法，因为以前公司那些不知天高地厚的所谓新贵老
是这样打击老程序员，而实际我认为他们只知道一些皮毛而已。如果数据库设计遵守3范式，就能达到
楼主所谓的合理设计，这个东西和oo无关，搂主可以去补补课。而我工作以后才发现，如果严格遵守
三范式来设计数据库，在有些应用，尤其是大数据量的应用里面是自找死路。既然有经验的总工都认
为有道理，我觉得数据库的设计应该有可取之处，和有经验的数据库开发人员作适当的沟通和协商就
应该能够很好地解决问题，一看人家的设计就火毛三丈，一点道理都没有，至少也要尊重老程序员
么。我曾经和一个老程序员谈过他的数据库后台的设计，结果发现他大量使用了现在JAVA世界里广泛
称道的设计模式的内容，比如FRONT CONTROL, FACADE之类，而他自己本身对oo/设计模式以无所知。
可见所谓的oo/procedure本身只是一个幌子，别把自己太当回事。
作为系分，考虑系统架构应该从多个角度去看，不要想当然，涉及到自己不熟悉的地方，更应该放下
架子多请教一下有经验的人,让最熟悉的人去做他最熟悉的事就好了。因为性能问题，我们曾经有不得
不把ejb做成的应用最后全部移植成存储过程来实现的惨痛教训。
随便说说，我也只是一个菜鸟，很菜菜的那种
Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:cloudeye 2003.04.23
当然，举的例子并不是真正的业务，在这个项目里，极端情况下会有
数百万条的记录。
我发现finbackplus可能太过敏感误解了我的真正意思，
"因为以前公司那些不知天高地厚的所谓新贵老是这样打击老程序员"，新
人有不断学习的动力，但是可能也会不懂得给老程序员留面子。但是我相信
“打击”是谈不上的。这个观点于老程序员自己来讲是不好的，
如果我们的数据库设计人员抱这个观点来的话，我会争取换一个人来做设计。
不管如何有经验如果在一个项目里不思进取怨天尤人只能对项目起反作用。
我觉得，面向对象确实有很多不同于传统开发方法的特性，对数据库设计的要求
也会和原来基于数据库的开发大有不同，不管资格多么老的程序员，应该认识到
这些差异努力再学习，适应新的的开发方式。论资排辈的思想就失去进步的动力，
也会给项目带来负作用。
“oo/procedure本身只是一个幌子，别把自己太当回事。 ”这句话确实不应该是
一个项目组成员所应该说的话。第一句话体现了对OO的无知和排斥，第二句话可以
看出作项目的不正确心态，更进一步，对人不对事，这不仅是作项目，也是作事的
大忌讳。
"尊重老程序员 "这是应该的，不仅要尊重老程序员，还要尊重新程序员，尊重所有
人，看得出来findbackplus是很懂礼貌的，但是，在技术问题上，不能窝窝囊囊，
你认为不对的，就要提出自己的看法。
项目组内有一个新来的毕业生，对solaris很熟悉，我有一段很常跑到他位置上问
问题(我一直用windows，但系统会在solaris上部署)；但是在概要设计的评审会上，
我们总工的观点我认为不对，也一点没有放松，只要认为正确，就要坚持观点。技术上
没有什么资辈可言，只有懂与不懂。
还是来说说正题，现在暂时我是这样来处理的：
首先项目组内进行概要设计的评审，我们的数据库设计人员也认同了系统设计。
接下来，我将DAO设计的任务分配给项目的数据库设计人员(通过项目逐渐熟悉学习java
并从CS转向BS开发，这是公司也是数据库开发人员所希望的)，他们基本可以胜任DAO的
设计工作，而且因为熟悉数据库会写得不错。
现在看来，效果还不错，在DAO设计过程中体现出来的问题甚至导致他们提出数据库结构
的调整要求。
大家的讨论给我很多启发，也更认真去考虑这个问题，从项目管理角度和技术角度。
Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.23
坦白地说我不认为你对OO真的精通，对象技术本身就是从传统的过程发展来的，在传统的过程开发里
面都有很多体现对象技术精髓的列子，即便是用pb，甚至c的程序里面，你都可以找到大量好手实现的
封装，重用，甚至组件化的例子。 你可以到陶清论坛，看看那些顶尖的pb好手，对对象技术理解是不
是比你更强？ 我在有些pb老手的程序里看到的重用和封装的程度，我现在也做不到这么好，那都是他
们多年经验的积累。
"第一句话体现了对OO的无知和排斥，第二句话可以看出作项目的不正确心态", 我只能说你真的比较
无知,至少比我无知。对真正的传统高手来说，对象技术只是一层纸而已，捅破了，就通了。对象技术
的大师和理论家无一不是从过程开发里走出来的。对象技术实际是传统过程开发里面一些很好实践的
总结。拿现在又开始热起来的COP/AOP来说，我是否可以说我用这些技术作开发，就可以贬低OO的价
值？就可以认为OO是一种要淘汰的东西？我是否可以跑到一个OO的大师面前，跟他说，现在是COP/AOP
的时代了，你过时了，你需要认真学习，你需要向我学习? 保持平等的心态，不要太把自己当会事
心理上的优越感，只会是暂时的。我手里就有现成例子，没什么经验的新手，3个月以后比那些自己鼓
吹2，3年j2ee开发经验的所谓老手强的多。3个月前是他开口闭口教育别人，3个月后是别人反过来教
育他。别太把自己当回事，在你成文高手之前，至于之后，就更不要把自己当回事了。
我曾经和不少老程序员谈OO，结果发现跟他们的沟通远比和一些所谓的新贵容易得多，至少他们不会
整天把OO挂在嘴上，做出一些不伦不类的东西。经验是一种很宝贵的财富，不是靠所谓的新技术短期
内能积累的。一个会在应用中，创造，并实践设计模式的老程序员，远比看了dp就在那卖的你所谓的
熟悉对象技术的程序员强的多，只要给予适当的引导，你就能看到效果。
一个过程开发的好手，成为一个OO开发好手的几率，要比一个oo新手，或者一个所谓的oo好手，成为
真正好手的几率高的多。这几年我看过太多我们所谓的OO高手写出来的惨不忍睹的东西，用JAVA不等
于你是OO的，用C/PB/PL SQL也不等于你就是非OO,开发技术的发展，无非就是为了提高开发的效率，
经可能的提高代码的重用性，可维护性，扩展性。很多方面，不管使用哪一种技术，很多东西本质上
都是相同的。oo不oo并重要，至少我认识的高手，从来不把oo挂在嘴上。至于所谓打击，只是一种说
法吧，坦白的说，好的程序员绝对不会怨天尤人，只有给他们一点点信心和时间，就可以做好。在我
团队里，我不会允许谁对老手说，你的那些都过时了的话。
作为一个所谓的OO的好手，如果不正视这些本质的东西，肆意否定一些东西，我觉得你是扼杀老程序
员的创造性。一个java好手，肯定可以成为一个c#好手，同样，一个PB/ORACLE的好手，肯定也可以成
为一个java的好手，编程的本质是相通的。
技术上没有资辈可言，但是换一个角度看问题，你会发现自己未必是对的。如果你能看到问题的本
质，你就有更好的解决办法。给予他们适当的引导，几个月以后，你会发现他们有些人会做的比你还
要好，这是我的经验。我不尊重老程序员，我只尊重优秀的老程序员，不管他是写什么的。
我是一个很菜菜的菜鸟，对前途很困惑的菜鸟，做菜鸟的唯一好处，就是可以胡说八道，又不会丢面
子。
Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:frenzieddragon 2003.04.23
"对象技术本身就是从传统的过程发展来的"这句话好像是错的，据我所知，面对对象技术和面向过程的
技术基本上是同时代产生的技术，只不过最近10年才被广泛应用而已。
Re:Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:finbackplus 2003.04.23
呵呵，被抓到尾巴了，俺不是学究，说得很不准确哦，不要砸我，我是菜鸟。
应该是有很大联系吧， 基于结构的过程语言出现更早一些，当时计算机硬件的条件决定了对象技术不
可能实施，所以对象技术是理论的，缺乏实用性，记得以前的教科书讲过函数的出现是软件开发式一
个milestone.对象技术的最早出现在50年代的lisp,和60年代的simula都有体现，真正投用实用是在80
年代以后，很多理论都是对在传统的过程开发去的经验上作的完善和修改。而过程语言也不断演化，
逐渐加入对象的特征，甚至演变成真正的对象语言。比如c->object c, pascal -> object pascal.80
年代后期,90年代出现的快速开发语言基本上都引入了一定对象特征，所以叫做object based德，比如
vb, pb.对象设计里面的重要概念封装，重用，抽象，都能在传统的过程语言里面找到对应的东西。
我见过的一些成精的老家伙写的东西，不写重复的代码-〉公用函数-〉函数库， 提高代码的可维护性
何易修改行-〉功能分解，简单化，专一化-> 对象职责？ 数据封装-〉结构. 很多东西都是可以相通
的。如果用的是pb/pl-sql就更多了，因为语言本身糅入不少对象的特性，那就用得更好了。 我见过
人家用PL-SQL实现的FRONT CONTROL, 和FACADE,还有近似的MEMENTO ， COMMAND
用传统的非对象技术开发走的是对象-〉过程，结构这样的路子，对象的概念还是有的，只是实现不同
或则限制于语言特性有些东西难以实现罢了，所以说作PB/ORACLE就不懂对象技术，我说那是胡扯，用
了JAVA就高人一等，动不动就说别人无知，那更是胡扯。我前面就说，搂主的表结构只是要不要遵守3
范式的问题，这要结合实际应用的情况。用不着提到那么高的高度，什么对象开发和传统开发的矛
盾。面向对象只是一种解决问题的思路，和语言之间没有必然的等号。我看过有家NX德公司的JAVA
CODE，一个类里面有几万行代码，一个方法有几千行代码，大量的CTR-C/V，这就是面向对象？
我语文不好，有些地方说得不明白，大致精神就是这样了，要扔砖头的继续扔。
Re:Re:Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:liu_ruyan 2003.04.24
俺菜鸟也来凑个热闹！
finbackplus 的观点：oo并不就代表着高人一等，好的过程高手照样可以写出很优美的程序！
我的观点： 如果懂得oo的话应该是比较容易达到上面的一般只有高手才能达到的境地！
另为楼主的建议： 如果为java来开发的话，可以考虑下
hibernate 和 jdo这两个东东，，应该会对你很有帮助的！
Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:johnsonqu 2003.04.24
确实如此啊！
做J2EE开发的，有时间的话，还是去看看EXPERT ONE-TO-ONE J2EE DESIGN AND DEVELOPMENT,里面有很
多中肯的意见。
另外，对于很多使用RDMS(目前的大部分情况)项目来说，采用ORM的工具或者JDO确实是比较理想的解决
方案。
Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:OOD需要数据库设计吗？ 发贴:steffyan 2003.04.30
转一篇，希望对大家有所帮助
对软件工程的一点看法(之三)--关于OO
空军一号 发表于 2003-4-9 1:13:38 软件工程 ←返回版面 [快速返回]
在网上看到的一些帖子里，很多人把OO和软件工程不加区分，实际上OO和软件工程是两回事，下面是一
些个人观点。
OO是一种软件分析、设计方法，或者说是思想。C++, Object Pascal, java等等高级语言，是将OO思想
用代码进行表述的手段。而软件工程则是用工程学的手段，对软件的全生命周期，包括需求、设计、编
码、测试、维护等各个阶段进行量化管理。Rose是一种软件工程的辅助工具，UML则侧重于在软件需求
与设计阶段，提供一套完整的，以OO的方式进行描述、交流的形式化语言符号。
从这个意义上来说，能够用OO进行思考，远比能够使用OO工具来的重要。实际上，用非OO的高级语言，
也能实现OO的设计。此外，我还想强调一点，OO与传统的结构化设计，或者面向流程的设计并不矛盾。
他们之间的区别，主要在于解决问题的方式或次序不同。正确的使用OO的方法，能够得到更好的系统结
构和可重用性，并且降低编码工作量。与面向过程的方法不同，OO更加强调设计体系的合理性。不合理
的OO设计往往比不合理的面向过程设计带来更多的负面影响。
但是OO也不是万能的，现在流行的编程语言往往是OO与面向过程的混合体。如C++和Object Pacal。这
主要的因为纯OO的编程语言，往往不能产生比较高效的代码。
即便是系统设计采用了OO，在编码的时候，对象内部仍然是面向过程的。因此，面向过程仍然是OO的基
础，做不好面向过程的代码，OO也是空中楼阁。
C++作为流行的OO工具，也有一定的缺陷。以C++为基础的类库，虽然功能强大，但是也带来学习周期长
的问题。要想掌握一个C++类库，如MFC，不深入代码，很难发挥出类库的潜力，写出好的程序。
现在我们很多的程序员，没有深刻的理解计算机体系结构，不了解编译程序的工作原理，不能灵活的运
用数据结构，更不清楚操作系统的工作原理。实际上来说，这种水平去做面向过程的Coding都不合格，
怎么可能去很好的OO呢？
我说这些话的意思是，尽管现在有了好的工具，好的教科书，并不能解决目前普遍存在的程序员能力的
问题。在实际运用OO之前，起码要做到两条：
1。Thinking in computer
2. Thinking in OO
JDO方面的问题 发贴:netwiser 2003.05.01
>另为楼主的建议： 如果为java来开发的话，可以考虑下
> hibernate 和 jdo这两个东东，，应该会对你很有帮助的！
想请问一下，在JDO的Cross Domain Transaction 方面如何处理？
我最近用JDO写了一个Persistence Framework，目的是把 Persistence Manager,
PersistenceManagerImpl进行封装，但在此过程中遇到不少麻烦。目前JDO 1.0Spec规定： 每个
Persistence Capable Object associates with a Persistence Manager，而每个 Transaction
associcates with a Persistence Manager instance，而且，在没有Transaction Active的情况下，
是不能对Persistence Capable Object进行 Modify，除非 explict define the
NonTransactionalWrite to TRUE。问题出在这里，一个Transaction 拖的很长，但还不是很麻烦，我
可以在Update开始前，Explict call 我的PM的preUpdate，启动一个Transaction，而后维护一个
Waiting Thread Pool，确保每次只有一个Thread Access this Transaction instance， update完
后，explict call postupdate，commit and notify the waiting thread。基于如此，我只能为每个
Domain associates一个 Persistence Manager Implementation，否则Transcation 跨度很长，但是遇
上cross domain而且需要一个Transcation中提交的scenario，就很难处理， e.g. Domain product拥
有一个PersistenceManagerImpl， Domain CreditCard也拥有一个PersistenceManagerImpl 各自负责
处理自身的Domain persistence requires，但我当我place order时，我要把OrderLineItem保存，同
时也要把CreditCard扣帐，而这时至少有两个完全不同的Flat Transaction，即我不能再一个
Transcation中embedded另一个Transcation。 我曾试想把Transcation 独立出来为一个Transcation
Manager，但又无法剥离Persistence Capable Object 与Persistence Manager的紧密耦合关系。
不知道是小的愚昧，未能悟透JDO的奥秘，抑或是JDO 现在的实现问题太多？ 望各位大虾有以教我！！
Re:JDO方面的问题 发贴:cinc 2003.06.10
没用过 jdo ，但用过其他两个 o/r mapping 的工具
以前在使用 castor 的时候也遇到了这个 cross domain transaction 的问题
castor 解决的也不是很好，在 一个 transaction 里获得的对象，送到 ui layer 更新后
就没法在新的 transaction 里把这个对象更新到数据库了
听说 castor 支持一个 long transaction 的冬冬，没仔细研究
用了一个变通的办法，把 update() 方法改成了下面的样子，把 ui 传过来的 对象再赋值到
persistence layer 里的对象。
AccountDAO.updateAccount(Account account){
Database db = getDatabase();
db.begin();
dbAccount = ... // get account from db
// set dbAccount with new values
dbAccount.setName( account.getName());
dbAccount.setSex( account.getSex());
db.commit();
db.close();
}
但如果遇到 nested class 就晕了。
最近在研究 hibernate，感觉蛮不错的
hibernate 使用两种方法来实现 cross domain transaction，真正实现 presentation layer 和
business layer 的分离：
1.Updating objects saved or loaded in a previous session
多用于 3 层环境
好像里面使用了 versioning 来 manipulates the state of transient instances
originally loaded in another Session （在db 的那个表里多了一列 version）
The <version> element is optional and indicates that the table contains versioned
data. This is particularly useful if you plan to use long transactions
2.Session disconnection
多用于 2 层 web 环境
同一个 session，从 db 获得对象后，先 disconnect()，并把 session 存放到 httpsession 里
然后让用户修改这个对象，提交后，再从 httpsession 中取得这个 session ，reconnect()，把
对象存放到数据库
这里的 session 相当于一个 transaction
下面摘了些文档：
1.In a three tiered architecture, consider using saveOrUpdate().
When using a servlet / session bean architecture, you could pass persistent objects
loaded in the session bean to and from the servlet / JSP layer. Use a new session to
service each request. Use Session.update() or Session.saveOrUpdate() to update the
persistent state of an object.
Usually update() or saveOrUpdate() are used in the following scenario:
the application loads an object in the first session
the object is passed up to the UI tier
some modifications are made to the object
the object is passed back down to the business logic tier
the application persists these modifications by calling update() in a second session
saveOrUpdate() does the following:
if the object is already persistent in this session, do nothing
if the object has no identifier property, save() it
if the object's identifier matches the criteria specified by unsaved-value, save() it
if another object associated with the session has the same identifier, throw an exception
2.In a two tiered architecture, consider using session disconnection.
When using a servlet only, you may reuse the same session for multiple client requests.
Just remember to disconnect the session before returning control to the client.
Session disconnection
The first approach described above is to maintain a single Session for a whole business
process thats spans user think time. (For example, a servlet might keep a Session in the
user's HttpSession.) For performance reasons you should
commit the Transaction (or JDBC connection) and then
disconnect the Session from the JDBC connection
before waiting for user activity. The method Session.disconnect() will disconnect the
session from the JDBC connection and return the connection to the pool (unless you
provided the connection).
Session.reconnect() obtains a new connection (or you may supply one) and restarts the
session. After reconnection, to force a version check on data you aren't updating, you
may call Session.lock() on any objects that might have been updated by another
transaction. You don't need to lock any data that you are updating.
具体可以看看 hibernate 2.0 的 Hibernate2 Reference Documentation
章节：
4.1.7. version
7.5. Updating objects saved or loaded in a previous session
13.3. Optimistic Locking / Versioning
13.4. Session disconnection
15. Best Practices
Re:Re:JDO方面的问题 发贴:finbackplus 2003.06.11
使用assigned id
同一个domain obj，save 了2次，第2次肯定出错，问题是出错了以后。再作load就把表锁死了。
对session做disconnect/reconnect，才可以。你又没有碰到。save出错有座rollback();
db 8.1 ee/ hibernat 2.0
Re:Re:Re:JDO方面的问题 发贴:cinc 2003.06.11
session 做 disconnect/reconnect 只是一种方法
还有另一种方法是 Updating objects saved or loaded in a previous session
不要用 save()，save 只能用来创建对象到数据库
如果不能肯定是创建，还是更新，用 SaveOrUpdate()，下面是例子：
public Company updateCompany(Company company) throws HibernateException {
Session s = HibernateSessionFactory.openSession();
Transaction tx = null;
try{
tx = s.beginTransaction();
s.saveOrUpdate( company );
tx.commit();
}catch(HibernateException he){
if ( tx!=null ){
tx.rollback();
}
throw he;
}finally{
s.close();
}
return company;
}
hibernate 会根据 unsaved-value 和 cascade 的设置判断是 save 还是 update
：）
Re:OOD需要数据库设计吗？ 发贴:pilgram 2003.10.30
不谈oo
1.这个例子，如果你的业务只有两种，用数据库设计人员的解决方案
2.如果要包含修改学生信息，其他学生考试成绩信息等新的业务，你就要按照java的解决方案
其实java的解决方案是一种更接近3nf（我没有仔细看），象楼上的说的，适合添加，删除，
修改信息。便于扩展维护
数据库设计人员可以创建两个view来 将java类型表格转换成任务需要的退课表、选课表
这里其实不是oo和数据库设计的矛盾。
Re:Re:OOD需要数据库设计吗？ 发贴:hezhihuang 2003.10.31
看到有人在为OO和DB争执的这么厉害,而且还罗列出如此之多的证据名言什么的,感觉到这个世界真是
他大了,学海无涯啊!
不过这种争执就类似于使用哪种编程语言的争执,说到最后还是为了使项目能够完成得更好,更成功.这
才是最终的追求目标啊!
看得出cloudeye和finbackplus两位老兄都是热血青年,慷慨激昂啊! 不过只要能让项目成功,又何必过
于在意是不是OOD/OOP呢? smalltalk是最完美的面向对象语言,但最成功的面向对象语言还是C++/Java
啊!
既然手下有那么多的PB高手, 又何必非要坚持让他们使用完全不熟悉的OO呢? cloudeye你是PM,也是系
分,但如果你设计出来的东西别人不理解或者不容易理解,那即使你设计得如何完美,也只是一个虚幻的
空中楼阁而已! 另外,我想衡量一个PM的最重要一条不是你用了什么技术,而是你这个项目的成败
啊! -------- 如果有一个输出Hello, World!的项目的话, 我倒是宁可使用Basic,简单的
print 'Hello, World!'了事, 这里感觉连C的main(...)都很烦琐,又何况java的class HelloWorld呢?
无论是产品和项目,都首先必须保证项目的成功;而项目的成功,又离不开"沟通"二字啊!
Re:OOD需要数据库设计吗？ 发贴:BirdGu 2003.11.04
就事论事的说，这不是OO和Relational的问题，这是要不要遵循第三范式的问题。更Java, PB都没关
系。
