俺是很老土的,由于项目需要,现在才开始学习Hibernate。其实Hibernate刚出来的时候,只是大概了解了一下,知道这是一个O/R Mapping的框架。但是具体怎么用,能够做到什么样子,没有一个具体的认识。现在从头学起,按照《Hibernate参考手册》提供的例子Step by Step做。做到Person和Event关联的时候,手册上给出的代码如下:
Session s = HibernateUtil.getSessionFactory().getCurrentSession(); |
很简单,很优美的代码哦,看起来很OO。这个代码实现的需求也很简单,就是将一个Person和一个Event关联起来。
但是当我看到输出的SQL语句时就愣住了:
Hibernate: |
姑且先不评价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,内容抄录如下:
注: Hibernate的复杂性是人尽皆知,想问一下Hibernate的退化用法,在JAVA***上发过这个贴子讨教,http://www.java***.com/topic/82107 <hibernate-mapping>
以下为JAVA***上的回答 drinkjava回答:答非所问,离题太远。 引用 drinkjava回答:你根本就没看明白这个贴子的观点,我的意思是完全不用OO思想,只是将Hibernate当作一个比jdbc顺手点的工具而已,我用关系数据库好多年了,也开发过上百个表的应用,不用OO不也照样做挺好?JDBC不行,可也没人说不准用JDBC吧? -------------------------------------- 引用 drinkjava回答:同上,不是我没理解,而是本来就没打算采用“对象模型” -> “关系模型”,而是直接一个表对应一个类,走的是"关系模型"的路子。 -------------------------------------- 引用 drinkjava回答: 咱笨,用不好关联映射,怕出错,所以干脆不用它,可关系模型咱还是很精通的,所有的关系就交给数据库去约束它好了。至于为什么还要用Hibernate,是相比JDBC和ibatis来说的:不用写很多SQL,有缓存,跨数据库,支持分页,Spring支持,总之好处一言难尽啊... -------------------------------------- 引用 drinkjava回答: 不知你是为了OO而开发,还是为了开发而OO? -------------------------------------- 引用 drinkjava回答: 不会这么恐怖吧?Hibernate很能干的,你google一下“hibernate多表查询”就知道了。 -------------------------------------- 引用 drinkjava回答: 可见笨人不只我一个啊,这个居然用了2年。Hibernate的这种用法确实很另类,与它诞生的初衷可说是背道而驰,但事实上,这种方式程序跑起来绝对没问题,问题是这种用法能否被团队接受,让我用起来心里有个底,这才是我发贴询问的原因。光一个人私底下用,当然没人会来说三道四,问题是能不能引入到团队开发中,作为一种替代JDBC的简易方案,而不是被团队中的高手当作异已一棒子打死,因为通常一提到Hibernate大家就会联想到ORM,这确实是一个很容易陷入的思维惯性,事实上,前面几个回贴都是这样,也不想想贴子要表达的是什么,就开始反驳了。 |
FeedBack:
首先谢谢你的答复。不是说Hibernate就是不好,存在就是合理,Hibernate有他适用的地方。对于Hibernate的理解和掌握我肯定没有你这么深,我想表达的意思是,Hibernate可能无法准确理解程序对于数据操作的需求,所以做了一些无用功(要解决这个问题,估计还真是得参考drinkjava兄的Hibernate“退化”用法),所以我有点不喜欢它。说到优化,我也相信你说的实际情况,但是抛开数据库的优化不说,单纯的SQL优化要比HQL和Hibernate的优化可能更加明了和简单呢。就像上面Hammer说的,对程序员来说,能直接看到sql是最放心的。我就是为了放心...呵呵 回复 更多评论