不选或许有千万种理由,但是选择hibernate只需要一个理由就足够了
选择一门新技术,首先要看这门技术是否能够满足目前应用的需求,我们承认任何事物都不会十分完美的同时,也在不断追求着能够为本身应用带来巨大价值的途径。
简单来说,就是因为我们很懒,所以我们会一直寻找能帮我们减轻工作量的东西。
因此,hibernate才能被社区广泛接受,这些团队选用hibernate到底是因为什么原因呢?
1.hibernate是一个orm框架,可以自动完成object和关系数据库之间的转换,加速开发。
这一点就是hibernate最大的特色,不管以前有没有玩过jdbc,看到了hibernate的hello world演示之后估计没有不赞叹的:“操作数据库怎么可能这么简单,hibernate简直是从火星来的哦。”
2.hibernate可以跨数据库。
这一点其实是实现了orm的后遗症,为了实现一个通用orm,就必须兼容主流的数据库,如果hibernate只能在某一个数据库上跑。那它肯定不会有目前的成就。
结果这一点就变成了很多产品开发的基础,这些产品只需要关注自己的业务,不需要考虑在不同的数据库之间进行迁移了,一切底层都交给hibernate,只做好自己擅长的事情,花最少的时间获得最大的价值。
3.hibernate上面附着了一大堆的扩展,hibernate-validator可以做数据校验,hibernate-search可以玩全文检索,hibernate-shard可以做水平分表。
随着不断的发展,hibernate俨然已经发展出一套产品线了,似乎我们只要选择了hibernate,就很容易获得上面说到得这些额外功能,那么到底是自己从头搞起比较爽呢?还是借助社区的力量比较容易呢?一般人还是会选择站在巨人的肩头的,如果所有人都喜欢自己玩,那开源社区也不会这么火了。
毫不脸红的夸完之后,下面是hibernate的问题:
1.封装严重,不容易理解底层实现,导致出现了问题不容易排查。
这个确实无可奈何,它做的太复杂了,但是纵观orm系列,openjpa之类的jar包大小也是在2m左右,这也就说明orm本身是复杂的,选用orm就意味着要负担它的复杂性,如果不愿意付出学习成本,还是选用更简单的实现比较好。简单实现意味着无法满足上述的优点,正所谓鱼与熊掌不可兼得,大家要在实际选型过程中仔细权衡才行。
2.有些人认为hibernate效率极其低下,无法应付庞大数据量的操作。
众所周知的情况是,系统的瓶颈往往会出现在数据库一端,因为我们可以搞20几台web服务器集群,但是加db server却不是那么容易的,一般都要经过水平分表才能实现这类需求。
而对于这种特种应用,说是用hibernate完成关键环节显然是笑话,咱们也不用多说了,还是采用专用的技术去搞定。
反过来,hibernate是否可以应对一般的应用呢?答案是肯定的,因为hibernate仅仅是在jdbc上进行的封装,只是自动处理了数据类型转换,并对每次操作都实现批量处理,相对一般的程序员来说, hibernate所实现的批量处理显然更高一些,与其让那些对数据库一知半解的人去写sql,反倒不如直接用hibernate还来的方便。