O/R Mapping是末，OOAD是本

我有个观点,不知道是否正确.
ORM工具使用的好不好,首先取决与OO设计是否好.
数据库都是会用的,但OO设计不是都会做的.
如果是事物脚本(Transaction Script)方式,用ORM工具
可能只会增加麻烦. 要是自觉得自己OO还不过关,那么
对ORM工具也不宜投入太大精力.

是这样的，如果OO设计的不好，用ORM反而是给自己制造麻烦。

严重同意....反之亦然..如果DB设计的不好...做ORM也非常费劲..比如我们现在公司的DBA非常喜欢把userid..username..这两个字段分布到每个和user关联的表中...这样他查询这些表时不需要与user表关联再读username...而且这老兄从来不用id字段...都喜欢根据业务逻辑建立联合主键...唔..痛苦异常

目前来看OO技术是很适合业务系统的。如果说OO是本,ORM是末的话,现在不少人可能有点本末倒置。

大家都说用Hibernate先进、用Hibernate代码量少，就要在下个项目上用Hibernate,可能发现除了SQL变成
HQL后，其它也没什么变化，还会觉得有些用SQL能搞定的事情现在用了HQL反到搞不定了。

我觉得这样的问题主要在于OO不行，OO不行又集中
表现在OOAD不行。而OOAD始终没有好的学习途径，
通常的GRASP，名词法这样的工具方法，面对实际的
项目显得力不从心（colorUml好象到是非常实惠）。
而各种教材样例又显得过于玩具。

想建议javaeye 是否能开辟一个样例区，提供一些从
实际项目中提取的样例，重点能讲解点OOAD部分，
这样才能本立道生。

这句话总结的非常精辟，确实非常多的人本末倒置了，所以用不好Hibernate。我自己幸运的是先有了OOAD的思路之后，才去意识到ORM的问题，才去寻找Hibernate这样的工具，因此少走了很多弯路。

OOAD实际上是最接近人类思维习惯的抽象逻辑分析方法，我个人认为其实不需要非要专业的去学习才能掌握，其实只要你能够抛开具体的技术，例如抛开数据库模型，抛开编程语言，抛开运行环境，当自己是一个不懂计算机的业务专家，集中精力去搞清楚业务规则，就已经可以很好的进行OOAD了。

的确是非常精辟，O/R Mapping 工具只是把好的锤子，OOAD才是成为建筑师的基本素质。

OOA可以如此，OOD则是另一回事。同时我不认为OOAD如此轻松。经过
深刻思考和大量实践，OOAD才有可能是一项乐事。
OOAD并不接近于人类思维习惯的抽象逻辑分析方法，OOAD接近自然本身的事实。

深有体会...
原来有一个delphi系统，现在用JAVA来做成B/S的。那帮老大死活接受不了hibernate，痛苦一阵后，只好放弃了。

不会吧？早知道你让我帮你说呀

还有啊，实际上这年头谁都会OO的（不信你随便拉出个人来问问OO是啥），就是OO的水平不同而已。

从hibernate中文网开始接触hibernate半年多了。一直没有在项目中正式用hibernate.(现在与关系型数据库打交道不多，开发webGIS)

问：
   1、有经验的说说，用O\R Mapping  我们是先有entry Object呢 还是先 数据库设计呢？说说各自会出的问题？  用hibernate能真正的自上而下 的设计、开发吗？ DB ---   POJO   都有相互转换工具。

     2、对于我们，OOAD要，数据库设计也要。 并且设计系统时都得考虑。
   从我的理解 现在的O\R Mapping   只是O  到  R 的转换工具。（可以这么说吗？） 我们现在缺的是 O  到  R 的设计工具，建模工具。