raynix 2003-07-11 11:47
> I found that hibernate and many DAO products load
> configurations from XML File, and it will cost too
> many times to finish it. So it is not glad experence
> to wait so long while debugging.
>
> EJB load configurations while depolying, some better
> than hibernate i think.
>

难道hib连载入设置这种事都做不好？

robbin 2003-07-11 12:27
如果你把Hibernate的SessionFactory配置到App Server的JNDI上，也是deploying的时候configuraton，不是首次运行的时候才配置。

关于debugging，Gavin King特别提到Hibernate的一个突出特点，大量采用reflect，目的就是为了最好的支持增量编译和增量调试。

当你首次使用Hibernate之前，肯定需要configuration，这个过程除load mapping file，还要设定Hibernation各种属性，而且还会生成一些sql语句待命，以便于运行的时候不需要临时生成，所以会有比较长时间（几秒钟）。

但配置完毕以后，就没有时间开销了，你调试中修改代码也不需要重新configuration，因为Hibernate采用优化的CGLIB实现高效的reflect（据称速度和普通get/set方法调用一样快），完全支持增量编译，增量调试。反到是EJB不能支持增量编译，增量调试，修改了以后必须重新编译，重新deploy。你说哪个debugging效率高呢？

IDE Support的问题，是个见仁见智的问题，Hibernate的作者Gavin认为没有必要，事实上有XDoclet的支持，根据Java代码可以自动生成mapping file，可以自动生成DDL。而且还有一些第三方的IDE工具可以进行HQL的调试。

前面已经讨论过了，小项目，数据库表比较少的时候，IDE能够做的很出色。但是数据库表比较多的时候，比如100张表以上的时候，你还能够用IDE很好的管理吗？这时候反倒是一些如ant，xdoclet，junit等自动化代码生成工具，自动化测试工具大显神通的时候了。

不过Hibernate没有GUI Tool也是它在2003 Editor Choice Awards中败给Toplink的重要原因。

robbin 2003-07-11 12:47
关于IDE tool的支持问题，还想多说两句。

其实IDE工具支持并不是所有的软件都必须应该有的功能。从某种程度来说，IDE工具的功能和灵活性永远也无法比拟命令行的威力。

我用过好几种Unix，包括Linux，FreeBSD，AIX，HP-UX，Solaris。习惯在Unix下工作的人来说，更愿意用命令行，而不是IDE。因为命令行实在太简单而强大了。简单来说，如果我想把机器中所有的log文件都删掉，Unix shell命令就这么简单的一个命令行：

find / -iname "*.log" --exec rm {} \;

就更不要说复杂的批量文件更名了，我到目前为止，在Windows的资源管理器里面也做不好这个工作。而使用awk,sed等等命令工具对文件处理的功能强大到Windows望尘莫及。

就Hibernate来说，通过ant，xdoclet等命令行工具的配合，其开发效率也是IDE所难以企及的。总的来说，习惯Unix的人比较喜爱命令行，简单而强大，习惯Windows的人比较喜爱IDE，易学易用。

Njord 2003-07-12 08:55
关于IDE工具我同意robbin的看法。
自己写编译脚本，用ANT来编译是很灵活的一种方式。
实际上很多IDE都调用ANT来实现它们提供的功能。

用ANT、XDOCLET可以完成生成mapping xml、产生sql文件、建表、测试、发布，可以参考一下xpetstore下的ant编译脚本。

guty 2003-07-13 19:06
>关于debugging，Gavin King特别提到Hibernate的一个突出特点，大量采用reflect，目的就是为了最好的支持增量编译和增量调试

robin的'增量调试'是指jvm的hotswap特性吗? 我的ide是eclipse,也支持hostswap,的确可以极大地提高开发效率.

>前面已经讨论过了，小项目，数据库表比较少的时候，IDE能够做的很出色。但是数据库表比较多的时候，比如100张表以上的时候，你还能够用IDE很好的管理吗？这时候反倒是一些如ant，xdoclet，junit等自动化代码生成工具，自动化测试工具大显神通的时候了

我是支持尽量用IDE的,在项目中把ant,xdoclet和maven都集成到eclipse中,各种开发过程(例如更新环境\编译\部署)能够尽量做到'一次点击',减轻开发人员的负担.
至于目前一些IDE的在ejb开发中的wizard,方向是很好的,可以可视化地维护个体代码,但缺点不够开放,不能很方便地和script结合,难以支持批量处理.
我比较看好andromda项目的思路,基于UML图,产生xdoclet代码,但它目前还不够成熟,中间环节太繁琐,影响开发效率.

guty 2003-07-13 19:15
>用ANT、XDOCLET可以完成生成mapping xml、产生sql文件、建表、测试、发布，可以参考一下xpetstore下的ant编译脚本。

现在可以不用花精力去自己摸索了,大家可以用apache maven来管理项目,maven已经提供了一套标准的项目构建过程,目录结构,script库和类库,现在,已经有越来越多的开源项目放弃了各自基于ant的构建过程,改用maven,包括apache的大部分java项目和xdoclet.

ah_cai 2003-07-14 08:47
我也支持guty的观点，尽量在IDE中完成开发过程，虽然我自己经常也使用命令行，但是降低技术门槛，让各级开发人员能够快速、有效的工作也是我们需要考虑的问题。
关于maven，我也是最近从IBM developerwork上看到一篇文章才知道的，大家可以看看：http://www-900.ibm.com/developerWorks/cn/java/j-maven/。我也比较有兴趣，不过还没有开始使用，希望和大家一起探讨。
blues 2003-07-14 21:56
在此之前大家对hibernate进行了很多讨论。由于我没有真正在项目中使用过hibernate，所以不敢乱说。但看了一些资料和使用hibernate的Sample后，我感觉使用hibernate并非会有根本性的好处(当然cmp也不是必须使用的)。
先列出2种后台层次结构:
1.一个使用hibernate的sample
sessionBean --> (domain object) -->DAO -->hibernate
2.我在上一个项目中使用的结构
sessionBean --> (domain object) -->DAO
比较上面2种结构，区别在于：
方式1在DAO中使用了hibernate进行persistence工作，实现对关系型数据库的操作；而我方式2中，是在DAO中使用jdbc直接操作关系数据库。

我的结论是:
1.方式1能做的事情，在方式2中都能做；而方式2能做的事情方式1不一定能胜任。例如在DAO优化方面，方式2要比方式1更灵活；

2.方式1在代码量方面不比方式2少。--实际上方式1需要维护的是o/r mapping 文件，而方式2可以通过代码生成工具方便地生成绝大部分代码

3.o/r mapping的概念，更应该是一个面向对象设计的原则。在实现的时候，直接在DAO使用JDBC操作数据库也是一种o/r 转换的做法。因此还是没有理由一定要使用hibernate。

说的片面之处，请各位指正.

robbin 2003-07-14 23:25
>> 1.
C语言能做的事情，汇编语言都能做；而汇编语言能做的事情，C不一定能做得到。在程序优化方面，用汇编更灵活。

>>3.
Java是面向对象的编程语言，JVM是用C++实现的。直接用C++也可以实现面向对象编程，所以没有理由一定要用Java。

按照你的逻辑我推论出上面的结论，你只从一个很片面的角度来看问题，结论肯定是很荒谬的。

>>2.
Hibernate的Mapping XML File可以用XDoclet自动生成。但我没有听说过JDBC代码能够自动生成的，哪个工具这么拽？

如果没有“深入”的研究Hibernate，没有丰富的JDBC编程经验，千万不要轻易得出结论。

blues 2003-07-15 22:49
to robbin:
谢谢指教。
>但我没有听说过JDBC代码能够自动生成的，哪个工具这么拽？

DAO生成工具海了去了。我自己用的是自己写的。一个工具针对自己的项目够用就足够了，不一定要"拽"得象万金油一样才用。

关于>>1,>>3，我想是这样的：c/汇编 与hibernate/jdbc 没有可类推性。在综合查询模块我们用hibernate吗？我还用的jdbc。

另外我想o/r mapping仅是一个历史阶段的技术。等对象数据库成熟了就不需要了.

robbin 2003-07-16 02:04
就具体问题展开讨论才有意义，但现在我发现陷入了无意义的空泛争论中，我实在是非常不喜欢这样的话题，如果不是在这个thread，我想我大概不会跟贴。

>>DAO生成工具海了去了。我自己用的是自己写的。一个工具针对自己的项目够用就足够了，不一定要"拽"得象万金油一样才用

不知道你对DAO定义是什么？如果大家对DAO的理解都是《Sun Core J2EE Patterns》上所定义的DAO的话，那么DAO接口的实现类的JDBC代码呢？你能用工具自动生成？我大概能够推测出你所指的DAO生成工具的意思，和我理解的自动代码生成不是一回事，所以也不必就这个问题讨论下去了。


>>c/汇编 与hibernate/jdbc 没有可类推性。

Hibernate完全是JDBC的高层抽象，实际上最后还是被翻译成PreparedStatement来执行的，如果你看过Hibernate源代码更清楚这一点。因此你的结论1绝对正确，只不过这本来就是一个毫无意义的结论。

C代码最后也是被翻译成汇编来执行的，优化代码汇编肯定比C强，因此C就没有使用的必要了吗？我大学教汇编老师的老师据说x86汇编指令全在脑袋里，对他来说，可能真的没有使用C的必要，汇编对他来说比C更有效。但绝大多数人还是更愿意用C的吧，就因为C编程容易，代码量少，效率高。

Hibernate同样的道理，可能JDBC对你来说比Hibernate更合适，但有更多的人基于编程容易，代码量少，效率高的理由更愿意用Hibernate。

或者举一个更有类比的例子来说吧！当你准备处理XML文件的时候，你可以用Xerces，但这需要你对XML有比较深入的了解，也需要你能够不厌其烦的使用那么底层的麻烦的API来进行处理；或者你可以使用基于JAXP实现之上更高级的API，例如jdom/dom4j，我想这是大多数人的选择，因为它更容易学习，编程容易，代码量少，效率高。要说性能优化微调，dom4j自然不如Xerces，进行高层抽象本来就是以牺牲一定的灵活性为代价的，这是谁都知道的道理，但没有人会因噎废食，大多数人还会选择jdom/dom4j，当然也有少部分人认为jdom/dom4j根本没有必要，用Xerces足矣。

>>在综合查询模块我们用hibernate吗？我还用的jdbc

为什么不用Hibernate？越是复杂的对象关系，越是多表的处理，Hibernate的优势越明显，你正好讲到一个Hibernate最应该使用的场合。反到是单表的操作，Hibernate没有使用的必要。


>>o/r mapping的概念，更应该是一个面向对象设计的原则。在实现的时候，直接在DAO使用JDBC操作数据库也是一种o/r 转换的做法。因此还是没有理由一定要使用hibernate

自己使用JDBC来ORM当然也可以，但既然有现成的为什么不用？何况O/R转换也没那么想当然的简单，你有考虑过复杂的组合和聚合对象的表映射处理吗？我就遇到过很复杂的复合对象，一个复合对象映射了好几个相关的表，这种情况你采用怎样的策略进行属性和字段的映射？从数据库中取复合对象的时候，是否同时把组合/聚合关系的属性一并取出？什么情况下需要lazy loading；另外，考虑到分页显示，是否自己准备写一个util class处理分页；考虑到性能问题，是否自己准备写一个PreparedStatement/ResultSet的缓冲；......

嘿嘿，如果你设计的如此深入，并且身体力行的做到的话，也就等于把Hibernate自己写代码实现了一遍，但既然有现成的，为什么不用，非要自找麻烦呢？


>>我想o/r mapping仅是一个历史阶段的技术。等对象数据库成熟了就不需要了

嘿嘿，这又是一个绝对正确，但是毫无意义的结论。哪个技术没有消亡的那一天？哪个技术不是一个历史阶段的技术？

bruce 2003-07-16 03:22
记得2000年我接触ORM的时候，就有一种解脱的感觉。自已拼SQL感觉真的象卖苦力。

Scott Ambler（写过精通EJB）在一篇文章中说过，自已想写一个ORM工作量非常大，他建议不要这样去做，重复劳动，考虑的东西太多。

现在正在代着以下的疑问在看hibernate：
1。关于类继承关系Mapping，不知道hibernate是用什么方法，
因为可以有三种选择：
*映射整个类的hierarchy到一张单表
*映射每一个类到每一张表（包括抽象类或Superclass）
*映射每一个具体的子类到每一张表

2。关于一表映射多类的问题

3。关于一类映射多表的问题

也许有些实际的例子就最好了。

guty 2003-07-16 08:14
>另外我想o/r mapping仅是一个历史阶段的技术。等对象数据库成熟了就不需要了.

对象数据库永远不会成为主流的。抛开具体技术不谈，计算机系统有一个显而易见的事实，就稳定性而言，数据>程序>界面。

jd2bs 2003-07-16 11:26
上面谈到CMP难以应付复杂查询,返回大数据量也较为低效;但CMP在单记录维护上确实有它的方便性.

因此我不想放弃CMP,我的想法是以CMP为主,BMP为辅(应付大量查询和sp);
这样的结合会不会有数据同步问题?应该怎么考虑解决?

yyanghhong 2003-07-22 03:51
看了众多高手的发言, 很是兴奋.
我个人认为, hibernate的出现是必然的, OR mapping不光是java中的数据库开发的解决方案, 对各种语言都一样, 从使用result set到value object, 再到分布系统中的entity object, 我们花了大量时间在persistence层的建设维护上. 一个好的OR mapping框架不光要帮助我们完成95%的persistence数据和数据库之间的同步, 而且要自动的实现数据结构映射的同步.
在windows客户端开发工具中, 考虑到内存的问题, DataSet的开发方式在很长一段时间为主流, 但随着PC性能的提升, 用对象封装数据的方式对处理中小批量数据变得越来越流行, 这样的开发框架也纷纷出现,象 DELPHI中的Bold, Instant object. 尤其是Bold, 他实现了从uml diagram和数据表, persistence数据对象, 表示层数据显示控件之间的全方位的同步.所有变化都可用工具完成, 不涉及代码的更改. 而且95%的数据操作sql都是在运行期动态生成的, 只有很特别的sql需手工来写
在java领域, 由于主要是在服务器端开发, 内存不是一个大的问题, 所以很早就使用对象封装数据, 但persistence层的开发长期采用手工的方法,
最多是用一些code生成工具, 这种方法只是开始方便, 更改维护都很麻烦.
hibernate的出现添补了java相比DELPHI的一些不足, 但还是有些晚了