除JDBC外的数据访问技术包括EJB，Hibernate，JDO，iBatis等，但凡是ORM的总要面对相同的困境，如果透明持久化的，苦恼就更多 --Java数据访问技术依然在缓慢跨越鸿沟，.Net社区的同学用不着眼热心跳：

1.查询语言--纷纷重回原来极想摆脱的sql，但实现得又不如SQL成熟。
因为QueryObject，Criteria API的可读性太差，最后所有技术方案都回到它们原来一力想摆脱的SQL的路上。而且，因为是重新仓促设计，都不如sql 的成熟，总有很多做不到的地方。像刚开始的EJB QL，几乎什么都做不了，而hibernate 3.0 HQL把h2的代码抛弃了重新实现才达到相对满意的水平。

2.积极载入和懒惰载入--不能如sql般每次随需定制
ORM与jdbc访问的区别，就是以包含关联对象的对象，而不是以sql自由定制的ResultSet，作为数据载入的主体。

积极载入策略在载入订单对象时，会接着载入顾客对象、产品对象，而如果产品对象又包含类别对象时.....整个数据库被拖了一小半出来。即使不玩连连看，clob对象的胡乱载入就够头痛了。

与此对应的就是懒惰载入策略，比如EJB的初始版本，据闻每个属性查询一次数据库，数据库往返次数多得吓人。

ORM方案会让用户自行定义这两种策略来达到平衡。一般默认采用积极载入，在一对多关联上定义lazy load，还有统一定义积极载入的层数。到了hibernate 3，更可以在列级别上定义lazy load。

问题是，上述的定义都在hbm文件，每种对象的载入策略只能定义一次。而不能像jdbc那样，根据不同的情况select不同的结果列。

顺带一个问题是那些信息不完全对象，比如产品只有序号和名字，不带其他信息时，在一个纯面向对象环境里不好表示，hibernate提供的component方案也不是太好。

3.透明持久化--对POJO的一些临时操作也会被持久化
因为持久化是透明的，很容易就会误用，对POJO进行的一些临时操作，一不小心就被保存进数据库中。再加上Session，事务的混乱，远远没有用jdbc跑DML语句那么容易搞清楚发生的事情。

而且，不是每个程序员都能习惯新的透明持久化环境，都对所用ORM系统的持久化策略理解深刻。何况这些策略以及整合它们的框架如Spring，还经常毫无提示的在升级时发生改动!!!

所以，每个使用ORM的团队，在项目过程里总会有闹鬼的几天......

非典型秃子：C++,也需要ORM啊！这确实是个讨厌的问题！

TN ：dotNet下的ＯＲＭ类库很不错，试试ECO与ＸＰＯ，效果很不错，可是不像hibernate 哪样是免费的．也可以试试ＭＳ的LINQ技术，非常好用．

风沙：业余跟专业的区别就在这 http://www.odmg.org/

charles：问题是，上述的定义都在hbm文件，每种对象的载入策略只能定义一次。而不能像jdbc那样，根据不同的情况select不同的结果列。

你只是懂hibernate而已。JDO/TOPLink都可以提供灵活的加载方式(Fetch plan)，对多一个POJO的加载方式可以根据页面显示的需要进行定义。EJB3 SQL中的 fetch join 也可以让用户根据需要去加载需要的关联表。

肥豆：现在所有的ORM,其实都是试图从O一方来解决问题，所以搞的很累，为什么不试图从M一方来解决了，如果数据库能直接提供对象，那不就不用这么穷折腾了吗！ :)

肥豆：Cache数据库就是能在后台写对象，并支持现在几乎所有的主流前台编程语言，而且全面兼容Sql92标准！ 是个好东西

白衣：@charles JDO/TOPLink的fetch plan我先去学习一下.EJB SQL的fecth不算啊,又走回sql手工定义选择列而已. 不过为什么fetch plan 进不了EJB3呢?还是进了我不知道?

charles：EJB SQL的fecth不算啊,又走回sql手工定义选择列而已. 因为ejb3专家组的某专家认为用sql + fetch join就足够好了。

原文出处及评论:http://www.blogjava.net/calvin/archive/2006/01/05/26791.html