O/R Mapping是末，OOAD是本

kgd924兄弟碰到的问题，我也深有感受，呵呵。
至于你说的 “我很想知道现在还有些什么样的公司在抓根本呢？” 我觉得能活下来的公司都在抓根本，公司的根本不是技术。这里是讨论技术的，就不多说了，呵呵：） 胡扯几句。

100个程序员有10个懂OO，却有90个懂Relation。很形象。没办法，现状如此。
不懂relation的人能懂oo吗，怀疑一下，呵呵

《UML和模式应用》这本，我买了第三版的，UML 2.0

为什么OO叫了这么多年，懂的人这样的少呢？

O/RM本来就是沟通OO和realation之间的东西,但重点还是在O上面

我觉得，“白猫黑猫，抓住老鼠就是好猫！”，在美国出差的时候，去美国的医院里面，他们有的部门还在用20年前写的terminal程序，人家用着一样的很舒服，而且没有换的意思。
我的观点是：只要能把系统写的扩展性高，好维护就可以了，“用什么技术最好”应该是个没有答案的话题吧，踏踏实实把项目做好就行了。

一个程序能用20年，如果这是企业核心业务的支撑系统，说明这个企业的业务组织和流程已经十分稳定了，这是一种成熟。这样稳定的业务领域在国内是很难存在的。
“只要能把系统写的扩展性高，好维护就可以了”——这一点是当然正确的，但是做到这一点是需要成本的，OOAD就是帮助人们降低这个成本，提高这个可能性的。
“用什么技术最好”——在具体的情况下是有答案的。识别现在的情况，找到最佳答案，这就是开发人员的工作。

我一直觉得，系统最重要的是稳定。
Hibernate不是说不好，在组员不熟悉的情况下，引入到项目中有很大的风险。而且对于后期的维护也带来困难，维护工作不可能派一个老手去做，而新手水平很有限（但很便宜）。

“只要能把系统写的扩展性高，好维护就可以了”——这一点是当然正确的，但是做到这一点是需要成本的，OOAD就是帮助人们降低这个成本，提高这个可能性的。


对于降低成本的问题，我觉得应该根据公司的开发人员的实际情况去选择技术，如果公司里的开发人员对JDBC的开发已经有多年，而且很好的技术沉淀，也有成熟的组建了，如果让她们去碰不是完全能够Control的ORM,是否会增加成本。
ORM是能节省一些成本，但其实很多公司的持久层组建也是不错的，这个真的是很难说清楚，不过还是那句话，抓住本质，软件是为客户服务的，做到系统稳定，易于维护，在可以接收的时间范围和成本范围内选择合适的技术就行了。

听说rdbms都是以关系代数为基础发展起来的，oo思想是以什么为基础发展起来的呢？集合论，还是自然而然形成的呢？