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的团队，在项目过程里总会有闹鬼的几天......