| Hibernate, 想说爱你不容易 |
|
| 作者是 YODA | ||||
| 2008-05-06 07:42:38 | ||||
|
俺是很老土的,由于项目需要,现在才开始学习Hibernate。其实Hibernate刚出来的时候,只是大概了解了一下,知道这是一个O/R Mapping的框架。但是具体怎么用,能够做到什么样子,没有一个具体的认识。现在从头学起,按照《Hibernate参考手册》提供的例子Step by Step做。做到Person和Event关联的时候,手册上给出的代码如下:
很简单,很优美的代码哦,看起来很OO。这个代码实现的需求也很简单,就是将一个Person和一个Event关联起来。 但是当我看到输出的SQL语句时就愣住了:
姑且先不评价Hibernate生成的SQL语句的效率如何,就这个功能需求而言,映射到数据库上的操作就是在T_PERSON_EVENT表中插入一行。但是Hibernate却执行了3个SQL语句!如果只是在写一段Demo的代码,这样无所谓,但是如果是真的在有大量数据的生产系统上运行的话,我相信前面两个SELECT语句的消耗会比最后一个INSERT语句多得多。请不要对我说:可以在硬件上优化,可以在数据库进行优化。这个不是同一个问题。做为程序而言,应该是力求准确,该做的一样都不能少,不必要的就绝对不要做。其实无论是原来的结构化编程还是现在的OO编程,一个函数或者一个方法,都应该是做且仅作一件事,越靠近底层逻辑的地方越应该这样。尤其是在中国特色的系统中,典型的特点就是数据量大+业务复杂。在东北某省移动公司的BOSS系统,有几个主要的服务每天的调用量在3000万(每个服务,他们的服务器上有大概20个这样的服务)以上,在月底和月初的时候能够达到5000万甚至更高,但是服务的执行时间保持在0.02s-0.05s之间,这个当然和数据库设计和优化有关,但是我无法想象如果在一件简单的事情之外做一些不必要的事情会有怎样的结果。在南方的某移动公司,用户量已经达到3000万,他们的系统指导思想就是:用最简单的技术去做最复杂的事情。 Hibernate的拥护者会说,O/R Mapping的框架降低了程序员的门槛,不用去熟悉SQL。难道HQL就比SQL真的简单很多么?再说了,SQL是必须的基本功,就好像能够熟练使用操作系统是每个程序员的基本功一样。因为现在成熟的主流数据库都是关系型的,这是根本。这也是为什么O/R Mapping的框架运行起来总是很奇怪一样,因为从根上是关系型的,要想转化成OO,必然就有一些很别扭的东西。以上面的例子看,如果单纯看代码,都能够明白是要给Person和Event建立映射,不需要其它的东西,因为personId和eventId都已经有了。但是Hibernate不理解,他也没有办法理解。 有朋友说,使用Hibernate能够便于团队协作。其实团队协作也好,系统的可扩展性、可维护性也好,和你用不用Hibernate完全不相关。关键是看你的设计,能否清晰的层次化、模块化;管理上能否协调利用资源等其它因素。
我比较推崇WebLogic Workshop 8.1里面的Control/Database Control/Customer Control的设计思路(八卦一下,WebLogic Workshop的设计者之一来自MS,原来设计Visual Basic的,所以在Workshop里面有很多VBer熟悉的东西),直接在方法的上面用Annotation的方式编写SQL语句,支持命名参数。在编译之后成为无状态的Session Bean。自定义Control(可以认为是业务逻辑层)负责事务控制,很好用。 喜闻iBATIS也是这种思路的(自己写SQL语句),看来要学学iBATIS哦。
技术没有绝对的好与坏之分,只有适合与不适合之分。我觉得Hibernate并不是很适合大型、大量数据的、复杂数据关系的应用。如果我是客户,我需要的是一个准确满足需求,高效、稳定、易于扩展的系统,我不会关心你用的是什么技术(收费的东东另当别论,呵呵)。 以上是一个Hibernate初学者的看法,欢迎大家不吝赐教。
在google这个话题的时候,看到了另外的一篇帖子,和我的想法有点接近,原文在:http://www.jdon.com/jivejdon/thread/31879.html 作者drinkjava,内容抄录如下:
|
||||
| 最近更新 ( 2008-05-06 07:42:38 ) | ||||

