深度吐槽hibernate

原创
2015/12/23 23:35
阅读数 1.4W

 

   hibernate 我很久都没有用了,最后一次用应该是3年前的一个企业项目,决定采用hibernate的并不是我,是我领导,我只是开发者。我所受的罪领导并不知道。正 如我的每个hibernate项目那样,每次我都是用的提心吊胆。尽管我从ejb1.1到hiberate,然后再到jpa都经历过,这种一脉相承的技术 我了解和应用了有14年,但我还是不敢声称精通OR Mapping,尤其是最近hibernate版本又都了些新概念和新Annotation,让我还觉得我是个hibernate新手:OR Mapping 也许就是个DAO错误的方向。


让我来吐槽一下hibernate这种DAO工具,并提一下我认为完美的DAO工具。

槽点一 容器设计的败笔。 系统的核心是模型,也就是JavaBean,使用hiberante的项目,JavaBean被持久化容器劫持这是第一个槽点。尽管对模型操作,在容器的 帮助下,能很快映射到数据库操作,然而,现在越多越多的DAO框架都避免设计容器,就算是JPA规范,也只声称了是个API,而不再提持久化容器了,因为 持久化容器已经不得人心了. 以下是使用hibernate经常出现的问题(但不限于下面几个)
1 容器内,对模型的操作我不一定得映射到数据库里,可容器会强制
2 对象在容器内,一切操作都很顺利,但出了容器,会有各种hibernate异常。须知应用并不只有hibernate。
3 修改一个对象的属性,必须先从数据库load进来,成为容器管理对象,才能修改

槽点二之hierbnate能提高生产力? 我早期接触hb,并没有被所谓的容器托管Bean所吸引(上面已经说了,实际上这是个高级陷阱),我只觉得以后添加,修改都只需要调用一下HB的api就 可以了,就算是查询,也貌似很方便,有load的方法。现在看来,这些功能,几乎所有的dao框架,所有公司自己的dao工具都有,我在2002年就做过 最早的dao工具,并能自动生成dao,javabean.现在,我在beetl基础上,做了更好的beetlsql,也完全具备这种入门级功能。 吐槽hibenate并不能提高生产力,是因为其他功能提供的太容易用错和导致效率不高了,以下是hibernate效率不高的几个方面(但不限于以下俩个)
1 不可控的生成sql,每个用过hibernate的人都见只有一次api调用,可能是one2many,也可能是lazylaod,但控制台满屏的输出 sql者情况,这导致性能下降,你可以说这是开发人员不精通导致的,可是,HB为什么要提供这种手段让开人员走到这一步,好的工具应该为程序员提供便利, 阻止程序员犯错。
2 难以调试的HQL。如果你需要得到数据库专家支持,数据库人员会拒绝你给他的HQL,他需要的是SQL,数据库也需要的是SQL。所幸我项目中没有人打算 给DBA培训HQL语句(这太疯狂了,DBA估计会暴动),HQL在我看来就是一个很鸡肋的功能。如果纯粹是为了跨数据库平台,不同DAO框架都有不同方 案,比如beetlsql就共用的sql语句放一个地方,数据库特定sql语句放到指定地方.常规的翻页,序列等特性,通过方言实现类就解决了。

槽点三:annotation表达力不足, 以fetch来说,我有的业务需要eger加载,有的业务需要lazy加载,hibernate显然做不到,唯一的解决方法就是加入更多的新 annotation来表达,如果还不做到,就让annotation具备脚本或者sql功能。可问题来了,这样的极限方式不就是我们属性的程序语 言+sql 方式吗。 hiberante现在是5.0也许到了25.0版本后,他可能真的是一门语言+sql的工具了,但这样有什么意义呢。 我认为annotation,最多只能描述表映射就可以了。很多其他框架就是这么做的。如下是一些经常的槽点(但不限于以下三个槽点):
1 fetch 模式 根据业务来的,但annotation只能一种,我选用哪种都不合适
2 我的数据库之间表关系并不严格(这常见),导致hibernate 都启动不了
3 我想敏捷开发,把已经确定的做出来,但hibernate要求我有完整的模型,否则,都启动不起来

大部分其他dao框架都不会出现上面的问题。

槽点四:程序中的SQL是个重要资产,需要维护,但hibernate并没有去做。HB 最早是只有xml配置文件,作者认为只要通过配置就能完成所有dao操作,但是后来发现不行,就又搞了一个HQL,结果发现HQL跟SQL完全不能比,最 后支持Native SQL. 就算这样的演进,但HB作者仍然没有意识到SQL才是DAO的核心, 需要重点维护。 这也是Mybatis,Beetlsql框架能让大家接受并喜爱的原因。
通过Java拼接hql或者sql问题不大,无非是把数据库调试好的的几十行sql拆开拼接就好了。但这样开发效率不高,更重要的是,维护效率低,一旦业 务有改动,sql机会不得不重新在java里拼接。hibernate 本来应该像sql那样提供sql拼接,但并没有,反而是mybatis,beetlsql在这方便做的很好。

越来越多的人意识到hibernte是个问题,从而转用了mybatis, jfinal,nutzdao,beetlsql 等这样的开源dao工具,我认为一个理想的dao工具,应该有如下功能是必须的:

1 好的dao工具,支持javabean模型
2 好的dao工具,在javabean基础上,不能干涉javabean模型
3 支持sql的维护,如像beetlsql 那样通过markdonw格式维护sql,或者像myabtis那样通过xml维护
4 支持跨数据库平台
5 简单的数据库操作无需用户开发,大部分dao工具都能做到这点,比如beetlsql支持新增,修改,根据模板修改,根据主键查询,根据模板查询等,至少40%的dao代码都不需要重写
6 代码生成,比如生成javabean,生成dao代码,生成查询sql语句等
8 dao工具并不能要求数据库完全符合数据库高级范式,也不要求程序完全的OO。
7 最为重要的是,dao工具必须是个工具,任由开发人员使用。
展开阅读全文
加载中
点击加入讨论🔥(57) 发布并加入讨论🔥
57 评论
86 收藏
8
分享
返回顶部
顶部