谈谈Hibernate令人不爽的地方

Java的话，目前来说最好的ORM就是Hibernate了，没有太多别的选择。用Java开发项目，我选择的框架无非也就是Hibernate/Spring/Webwork

为什么不用ibatis呢  H没用过  不知道好在哪里
不过ibatis的SQL几乎就是保持原样的   看你们的说法 这个好像是和H最大的不同吧
难道这个是H的优点？

喜欢JDBC的应该会对ibatis比较感兴趣,只是写配置文件时要小心点,了解Jakarta commons下的BeanUtils和DbUtils子工程也许可以想象SQLMap是如何实现的,ibatis的源码我没看过,也许它为了追求性能使用了字节码生成或其他技术,而没有使用Java Reflection机制,都是推测,有时间再看看它的源码!

喜欢Hibernate大概是因为它为你考虑了许多你没有考虑到的,用时常会说"Hibernate真强,这个也帮我想到了,我还担心......",如果看过ORM理论上的东西,也许会深深的喜欢上Hibernate,只是它的HQL让人感觉讨厌!

哎,哪有十全十美的东西呀!?

还有一个严重问题：动态性。
字段的调整是比较常见的软件维护操作，
用上Hibernate后，这个功能就不太容易实现了。
字段的调节主要涉及三个地方：数据表、JAVA实体类、映射文件。
数据表的调整比较容易实现，而JAVA类、映射文件都不大容易在运行时动态更改，即使在运行时更改了、编译了，如果不重启，也不能正常工作。
现在能想到的办法只能是预留几个字段，以备不时之需。

在开发时用P6Spy来拦截一下，就可以得到最终的SQL语句了啊，而且不要修改一行代码，只要更改一下配置即可。
当然你也可以结合SQL Profiler或IronTrack SQL来进行图形化的显示并进行性能调优，而且它们可以根据结果帮你生成索引脚本。

偶严重反对robbin对于HSQL的看法，如果没有HSQL的话，让偶回到过去那种写一个产品，要在N种数据库上调试不同的SQL兼容性，简直是噩梦啊。
COC就更没有啥话好说了，你完全可以给Hibernate加个COC plugin，只支持native PK，只支持1:N，只支持字段和数据库栏位同名。批评Hibernate不够自动化，就象批评手自一体的BMW比自动挡的KIA难用一样好笑...

Hibernate生成的SQL倒是没有啥感觉，因为基本上hibernate.show_sql都是false，只有很特殊的调试情况下，才需要打开这个参数去看生成的sql是怎么样的吧？

给一个构建函数：
public class Department(Department d, Integer employeeSize)

然后写成这样：
SELECT new Department(department, count(employee.id)) FROM .....

不就OK了吗？

我尝试过这种做法，不过记得好像以前调试的时候Hibernate报错啊。啥时候再调一把。

不过如果类似的业务场景中，我总觉得用构造函数不是一个很好的做法。因为可能一个构造函数只能满足单一的业务场景，如果现在再来一个类似的业务场景，这个构造函数就无能为力了。

我同意Readonly的观点。如果不用hql,想实现数据库兼容就太难了。
举个例子，在很多手工录入的表格中都要记录录入时间/操作人/备注，我在java中使用date/person/comment来表示，可是java的关键字和sql的是不一样的，不同数据库也有各自的扩展关键字，上面那几个字段很可能就是某种数据库的关键字。用hql,我所有的查询语句就可以保持统一，切换数据库只需要修改mapping。实际上我写了一个自动根据数据库关键字修改mapping的类，这样连mapping文件也只需要一个。

对ror我不是很了解。我想知道如果已有的数据库中有的列名是ruby的关键字，或者ruby中的字段名是sql的关键字，这个时候ror如何处理？

简单的方案确实能解决大部分问题，所谓的80/20原则。但是有的时候就是需要复杂的解决方案。间接层次越多，系统就越灵活，能解决的问题就越多。

记得以前robbin还说过，Hibernate生成的SQL，非常的优化，效率极高，非JDBC顶级高手，勿须尝试写出比Hibernate更加好的SQL。

怎么现在就成了：“现在极其厌恶Hibernate生成的SQL，又臭又长，极难阅读。”？