谈谈Hibernate令人不爽的地方

复杂的对象映射，源自企图用一个优美的object graph，在各层来表达实体关系。让一个业务方法返回一个Domain Entity比返回一个map, array好看得多。



比如这个，最省力的方法就是返回一个array 好了。虽然看上去不那么OO。

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

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

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

1，save(Foo f);不能通过f对象往里面传递哪些字段更新、哪些不更新；

2，多主键问题无主键问题（不妨假设就是没有可以为以确定对象记录的情况，sql本来就是操作集合的）；

机器自动生成，而且还得考虑不能触犯到保留字（java sql 数据库自身），这样多的要求，还得易看！其实hibernate做得很好了，只是我们不知道他们所考虑的。

我觉得不爽的是如果HQL要想使用左右连接，必须先配一对多，多对多才能使用。如果不配，那就不能用。我的系统里都没配，所以碰到左右连接只能用native sql，但框架里又是设计成OO的，用native sql非常别扭。

做报表时，用Hibernate生成一个复杂的SQL语句，真是煞费心思，左连右连痛苦，后面就只能直接用JDBC来实现，用hibernate实现对象add,update,delete是容易，但是，复杂的业务，就没法容易实现了

一个软件，一个技术，最重要的是可持续性吧，这几年，不仅仅hibernate,其它的开源软件为可持续性做了多少努力？不知道，我觉得不会超过10%，可能更低。
做为一名java程序员，从职业生涯的角度来说，应该了解一些更为持久的，不是昙花一现的技术，从技术的角度来说，应该了解一些低层基础一点的东西。

ps:
来自国内某技术论坛的观点，对于一个企业级的应用系统系统来说，解决oracle8i,9i到oracle10g的需求很大，从sqlserver迁移到orcle的需求并不多。
除非：1，它不是企业级系统，2，dba那时候头脑发晕。

复杂的业务请写到存储过程中去，这是最高效的办法。