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或其他数据库操操作。
对此,你的看法又如何呢?