Goingmm

真不敢想象,如此的ORM框架,仅只有一位核心程序员(也不知道是真还是假).作为对JDBC的轻量级的对象封装,hibernate确实有很多优点,这里相信大家都比我清楚,但是缺点也不是没有,比如批量操作,我要指出一点点不足,hibernate的映射生成工具不是很好用(至少几个月前是这样, 不知道现在有不有成熟点的),不管是hibernate自带的那个叫什么dll2hbm,还是xdoclet,或则eclipse插件形式的生成工具,都会根据不同的情况出现不同的问题,出现问题的唯一办法就只有手工改配置文件.
  回复  更多评论
  

回复人名字可以随便写，也可以冒充别人，所以没有必要用真名字。

为什么要用　Hibernate ？

我只觉得增加了学习时间，等哪天我精通了　Hibernate ，Hibernate 又过时了。

  回复  更多评论
  

Hibernate 比 CMP 好在哪里？  回复  更多评论
  

对头，先想为什么要用，再讲如何用。  回复  更多评论
  

crud还是很有用的

但对hql还不是很满意

hbm和pojo最好手工改, 自动化工具无法胜任, 特别是已经在运行的项目  回复  更多评论
  

Re:
2005-11-04 10:13 | Water Ye@ITO
hbm和pojo最好手工改, 自动化工具无法胜任, 特别是已经在运行的项目


手工改容易弄出很多新Bug出来，特别是已经在运行项目。
如果已经使用了EJB，只是用Hibernate来做持久层，最后还是需要在容器内测试，享受不到轻量级系统的好处。
  回复  更多评论
  

都裸起，我也裸露一盘，goingmm不介意吧？
转摘一篇《Hibernate的优点 》：

一、Hibernate是JDBC的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。Hibernate可以用在任何JDBC可以使用的场合，例如Java应用程序的数据库访问代码，DAO接口的实现类，甚至可以是BMP里面的访问数据库的代码。从这个意义上来说，Hibernate和EB不是一个范畴的东西，也不存在非此即彼的关系。

二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。

三、Hibernate不能用来直接和Entity Bean做对比，只有放在整个J2EE项目的框架中才能比较。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：

传统的架构：
1) Session Bean <-> Entity Bean <-> DB
为了解决性能障碍的替代架构：
2) Session Bean <-> DAO <-> JDBC <-> DB
使用Hibernate来提高上面架构的开发效率的架构：
3) Session Bean <-> DAO <-> Hibernate <-> DB

就上面3个架构来分析：
1、内存消耗：采用JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。

2、运行效率：如果JDBC的代码写的非常优化，那么JDBC架构运行效率最高，但是实际项目中，这一点几乎做不到，这需要程序员非常精通JDBC，运用Batch语句，调整PreapredStatement的Batch Size和Fetch Size等参数，以及在必要的情况下采用结果集cache等等。而一般情况下程序员是做不到这一点的。因此Hibernate架构表现出最快的运行效率。EB的架构效率会差的很远。

3、开发效率：在有JBuilder的支持下以及简单的项目，EB架构开发效率最高，JDBC次之，Hibernate最差。但是在大的项目，特别是持久层关系映射很复杂的情况下，Hibernate效率高的惊人，JDBC次之，而EB架构很可能会失败。

4、分布式，安全检查，集群，负载均衡的支持
由于有SB做为Facade，3个架构没有区别。

四、EB和Hibernate学习难度在哪里？

EB的难度在哪里？不在复杂的XML配置文件上，而在于EB运用稍微不慎，就有严重的性能障碍。所以难在你需要学习很多EJB设计模式来避开性能问题，需要学习App Server和EB的配置来优化EB的运行效率。做EB的开发工作，程序员的大部分精力都被放到了EB的性能问题上了，反而没有更多的精力关注本身就主要投入精力去考虑的对象持久层的设计上来。

Hibernate难在哪里？不在Hibernate本身的复杂，实际上Hibernate非常的简单，难在Hibernate太灵活了。

当你用EB来实现持久层的时候，你会发现EB实在是太笨拙了，笨拙到你根本没有什么可以选择的余地，所以你根本就不用花费精力去设计方案，去平衡方案的好坏，去费脑筋考虑选择哪个方案，因为只有唯一的方案摆在你面前，你只能这么做，没得选择。

Hibernate相反，它太灵活了，相同的问题，你至少可以设计出十几种方案来解决，所以特别的犯难，究竟用这个，还是用那个呢？这些方案之间到底有什么区别呢？他们的运行原理有什么不同？运行效率哪个比较好？光是主键生成，就有七八种方案供你选择，你为难不为难？集合属性可以用Set，可以用List，还可以用Bag，到底哪个效率高，你为难不为难？查询可以用iterator，可以用list，哪个好，有什么区别？你为难不为难？复合主键你可以直接在hbm里面配置，也可以自定义CustomerType，哪种比较好些？你为难不为难？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么情况下用哪种方案比较好，你为难不为难？

这个列表可以一直开列下去，直到你不想再看下去为止。当你面前摆着无数的眼花缭乱的方案的时候，你会觉得幸福呢？还是悲哀呢？如果你是一个负责的程序员，那么你一定会仔细研究每种方案的区别，每种方案的效率，每种方案的适用场合，你会觉得你已经陷入进去拔不出来了。如果是用EB，你第一秒种就已经做出了决定，根本没得选择，比如说集合属性，你只能用Collection，如果是Hibernate，你会在Bag，List和Set之间来回犹豫不决，甚至搞不清楚的话，程序都没有办法写。


  回复  更多评论
  

“还是没的名字的”? 建议楼上的兄弟还是留下一个别名吧!!
Re: 为什么要用Hibernate ？ 我只觉得增加了学习时间，等哪天我精通了　Hibernate ，Hibernate 又过时了。
个人想法：学习是看自己的兴趣了，如果对这个感兴趣才会去学习。我不建议完全没有兴趣，纯粹为了做项目去学习。这样效果也不会很好。在这里，我不愿意去做一个技术的布道者。只希望尽量能在使用以后，用平常心去讨论

Re:Hibernate 比 CMP 好在哪里？
这个问题我也没有深入的去研究过。列出几个供大家参考吧！
1） CMP要求所有的访问操作都在事务环境中，非事务方式的访问不受支持。提出了一个全新的事务模型（method-based descriptor)。hibernate没有试图创造一个更新的模式，相反，Hibernate沿用了传统数据库的Transaction编程模式。
2） 继承是对真实对象建模时常用的概念，但CMP并不支持它。CMP在组件的定义和实现时并不一致，在具体实现一个EntityBean接口时，实现的类可以具有继承关系，但在定义这个EntityBean时却不行。类之间的关系也只是在接口之间，而不是在实现类之间，因此这些关系也不存在多态性
3） CMP虽然也有Local接口，但是Web层还是需要通过Remote接口访问EJB层的数据,序列化、网络调用、创建大量的对象，都是性能降低的原因
4） CMP很难实现动态Query，这是因为它基于代码自动生成技术，即最终的执行代码是在部署编译时生成的。hibernate则有根本的改变，它基于reflection机制，运行时动态Query是很自然的事。另外，hibernate几乎支持所有的SQL语法。

  回复  更多评论
  

我的名字就先叫“没的名字的”

我赞成用hibernate不用复杂的JDBC的方法（虽然我用JDBC比用hibernate要快，我就是上次参加那个不准说名字的项目用了一下hibernate，现在都忘记了）。

关于性能问题：
用CMP的时候，只是做查询慢。
但是可以用JDBC来做查询啊。用JDBC只做查询应该不复杂吧？没有必要用hibernate了。
还有就是使用SessionFacade做门面，CMP根本不需要远程接口。
EJB2.1规范允许把无状态的Session Bean弄成WebService，既然要效率，还做什么WebService？ 传输XML是比较慢的。

不知道什么时候计算机的性能会才会因为达到了物理极限而不能再提高了，也许到了那个时候又有新技术变为现实了，比如量子计算机。  回复  更多评论
  

用JDBC做查询有个缺点，就是程序员可能会忘记关闭打开的数据库连接。

在开发程序的时候，可以在AppServer里设置连接池的最大连接数为1，强迫程序记住关闭连接，不然查了一次就不能查第二次了。  回复  更多评论
  

上面是“强迫程序员记住关闭连接”，是程序员不是程序，少打了一个字。  回复  更多评论
  

上面的上面的上面我说“用CMP的时候，只是做查询慢”。
现在要更正一下，是“做查询返回大量结果的时候慢”。

还有就是用CMP做查询返回大量结果的时候，只能返回Collection的问题。用JDBC也能返回其它类型，比hibernate还要灵活。


  回复  更多评论
  

呵呵~~ 汇编也很好，但是不见得有很多人用

不否认JDBC的优点。但是眼下J2EE项目开发，我们现在的选择还会是JDBC吗？  回复  更多评论
  

我是说如果只做查询的话，可以用JDBC，没有必要用hibernate了。

用hibernate会更麻烦。


用JDBC只是用来解决CMP的致命问题。


具体就是做只读的DAO，用Session Bean来调用DAO。  回复  更多评论
  

Hibernate的查询SQL经过优化处理。估计用JDBC没有点功力的也写不出来。还有他可以减少很多无谓的数据库交互。他能缓存下查询的记录。各种方式支持你自由配置。当然你也可以自己去实现这些功能。但这基本上是没有必要的

我们还是不要再无谓的争论这个拉，我发觉这里离题已经越来越远了。呵呵！  回复  更多评论
  

我知道你们现在一起住的三个人有两个都参加过上次那个不准说项目的真名字的那个用 Session Bean + hibernate 的项目。

我更喜欢用CMP，虽然我没有在大项目中实践过。

你慢慢猜我是哪个哈。  回复  更多评论
  

1) 知道我们现在在北京住一起的三个人，肯定是一个比较乐观开朗的人，关心时事
2) 知道我们参与过并不能说出项目真实名字，那么一定是中国人，而且参加过这个项目
3) 你的刷新频率这么快，而且出没这么孤独。现在一定不在CTU-SDC，并且新加坡Office不能打开我的这个blog。
4) 有连续三次回帖补充的记录。你的年龄不会超过25岁
我还是记不起来。记得上一次听人说喜欢CMP还是去年，一个很牛B的架构师[name is secret]。All men like CMP he saied 。可能碰巧给你听见了，呵呵！~~~愿意的话，就把你的名字告诉大家吧，我们不要再浪费blogjava的硬盘空间了。本来就很珍贵的。  回复  更多评论
  

goingmm，你在搞侦察所，“天黑请闭眼……”  回复  更多评论
  

看见你在那里乱分析我是谁，我回家了都忍不住要回复你。

我就是那个平时喜欢一个人玩，被报表项目浪费了一大半青春的6山酒林。

我忘记了Hibernate，还没学会SQL Map，连iHis我也快忘完了。  回复  更多评论
  

6山酒林是啥子哟？  回复  更多评论
  

真是的，测试一哈  回复  更多评论