ORM透明持久化方案面对的共同困境
原文出处及评论:http://www.blogjava.net/calvin/archive/2006/01/05/26791.html
作者：江南白衣
上次FB的吹水摘录：
除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的团队，在项目过程里总会有闹鬼的几天......
