ORM的再思考

 昨天magicgod发表了他的关于hibernate,jdbc,sql的思考。 在Matrix和其他论坛引起广泛讨论。

　　jsports对此文提出了他的反面看法， 并在他的blog作出了总结，摘抄如下：

　　jsports对magicgod其所提的：三个问题，不太赞成。

　　1.对象与数据库的映射。

　　关键在于对象关系的映射，但是没做到很理想，配置过多，控制复杂，另外还会出错。其实本质在于对象不够自由。

　　为什么要使用ORM？是为了避免SQL带来的麻烦，具体麻烦我就不一一说了。但又不能不使用SQL！因为现在是RDBMS占主流，不能说服用户使用不成熟或使用范围不大的ODBMS。那么有什么办法即使用SQL又能去掉或减少这样的麻烦 ？通过一次或一层封装来使用SQL或许能够达到目的。
那么就需要配置.但这样做有一定的缺陷.因为在关系上,需要说明的问题比较多,导致配置的复杂.
想使用这个技术,还想不受这个技术的约束,这是个问题.

　　JDO等的出现都是对SQL的使用的经验的积累,然后象模式一样,使用的多了并证明这样能解决问题,那么就抽取出来成为了一个持久框架.

　　2.事务处理。

　　这点上更容易出问题，相对于各种各样的事务管理器，要兼容是一个大问题，总归在各种应用服务器上有很多问题。其本质在于创建了一个自我数据存取小环境，必然面临各种兼容问题。

　　事务,hibernate的文档说的很清楚.可以使用各种事物,包括JTA. 对于各种java的事物管理器,应该都是支持JTA的. 那么既然事务管理器支持并且hibernate也支持JTA,为什么不使用? 当然,即使使用还有使用方法问题. 想必是使用方法不太简洁导致的该问题.尤其是那种 动辄 openSession和beginTransication的那种!是经典的出问题的地方.真正的使用不是这样的.
提示一下,方便的使用Hibernate jta事务需要做部分额外的工作,但这个是值得的.

　　3.HQL语言。

　　建立对象查询语言，类SQL，但是不同于任何一种SQL，调试环境复杂。本质在于创建了一种语言，增加学习成本。

　　hibernate的hql为什么要出现?hibernate作为ORM,本身要提供一个Object类型的查询result .那么如何从sql的ResultSet转化为Object?是直接转?还是间接的转?这是个问题.如果直接转化,可以想象难度相对大些,而且不见得有什么好的效果,例如导致执行时间过长等.那么在SQL的基础上，进行适当的修改，可能比直接使用SQL效果会更好些。HQL的语法并不复杂,稍微看了文档就能够上手使用。当然复杂的功能,可能要花些时间.并且不仅仅是hibernate，很多ORM以及EJB（我认为Entity EJB也是ORM），都有自己的Query Language。

　　这些QL在运行时最终都会把其转换为SQL去执行。也就是说，并不是单独的一种语言，是一个中间语言，是为了把ResultSet转化为Object的这个过程方便的中间语言。总而言之，ORM技术不是一个新的技术，而是对JDBC OR ODBC进行了一层封装显露出的另外一个面目。其操作，终归会转化为SQL或其他数据库操操作。

　　对此，你的看法又如何呢？