作者:江南白衣    
 
   上次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的团队,在项目过程里总会有闹鬼的几天......