Hibernate和Mybatis应该如何选择

介绍

HibernateMybatis都是J2EE领域优秀的ORM框架。不同于纯JDBC方式在数据操作时的繁琐,他们很好的隐藏了前者的一些操作细节,提供给调用方更为友好简洁的API。

Hibernate

Hibernate更自动化,抽象层次更高,更面向对象。开发者在Hibernate中配置好Java Bean同数据库表的映射关系以及Java Bean之间的关联关系后,就可以专注于业务代码编写,仅通过Hibernate的API进行数据库操作,最终提交给数据库执行的SQL由Hibernate自动生成,在正确使用的情况下,其生成的SQL都是高效妥帖的。值得一提的是,这些配置都是一次性的,不需要反复修改。

MyBatis

比起Hibernate来说,Mybatis的工作方式显得不那么自动,所以也有人称其为半自动化框架。使用Mybatis,开发者不光要关注业务代码怎么写,还要关注其对应的SQL该如何写,并将这些SQL配置在Mybatis中,而业务代码的变更还可能导致这些配置被反复修改。

如何选择

理论上来说,Mybatis这种半自动的方式,能够让开发者能很细粒度的控制持久层的运作方式,开发者直接编写SQL,从而更好的控制SQL性能。而Hibernate提供了更高层次的抽象,屏蔽了SQL编写细节,要完全掌握他有一定的学习成本。

但理想很丰满,现实很骨感。姑且不谈Mybatis需要将业务操作SQL反复不停的修改进配置文件。就如何写出高性能SQL这点已经让很多开发者力不从心。

传统软件较为依赖数据库,很多软件甚至将逻辑写入数据库存储过程,且由于用户量和数据量并不大,往往系统也不涉大规模分布式,部署服务器较少。在服务资源有限的情况下,为了让软件性能更高,写出更高效的SQL,这要求传统软件系统的开发者对数据库原理,SQL解析过程有很充分的了解。

互联网浪潮袭来,更便宜的硬件,更便宜的云服务,新时代的开发者们往往不太关心单机性能体现如何,很多不具备数据库性能调优的专业知识,他们开口闭口的大数据库,分布式,Hadoop。但很多对SQL的IN 和EXSITS 的区别,子查询的和JOIN的性能对比都没有很好的认识。这些糟糕的SQL导致软件系统在数据量并不大的时候便早早暴露出性能问题,我个人所在的团队便屡次出现这种情况。

基于此种现实,我认为,在没有特殊应用场景(特殊到Hibernate都不支持)时,选用Hibernate作为持久层框架显然更合适。