持久层框架JPA与Mybatis该如何选型，java常用框架面试

最新推荐文章于 2025-02-26 19:22:31 发布

JavaScript高级

最新推荐文章于 2025-02-26 19:22:31 发布

阅读量757

点赞数 15

分类专栏： 2024年程序员学习文章标签： mybatis java 面试

本文链接：https://blog.csdn.net/m0_60388419/article/details/137265414

版权

2024年程序员学习专栏收录该内容

271 篇文章

订阅专栏

一、现状描述

目前java 持久层ORM框架应用最广泛的就是JPA和Mybatis。JPA只是一个ORM框架的规范, 对该规范的实现比较完整就是Spring Data JPA（底层基于Hibernate实现），是基于Spring的数据持久层框架，也就是说它只能用在Spring环境内。Mybatis也是一个优秀的数据持久层框架，能比较好的支持ORM实体关系映射、动态SQL等。

笔者在学习这两个框架的过程中，看过不少的帖子，每当有帖子比较这两个框架的优缺点，就引来一场论战。从笔者的角度，为什么国内的开发人员或者开发团队较少使用JPA？为了避免有人抨击我，我特意去做了一下国内某度指数搜索，这个数据骗不了人。

图中蓝色线条为Mybatis搜索量，绿色为JPA搜索量。如果你换一个国外的搜索指数，你会得到一个完全不同的结果。那么这是为什么呢？我们还要从JPA的特点说起：

JPA对于单表的或者简单的SQL查询非常友好，甚至可以说非常智能。他为你准备好了大量的拿来即用的持久层操作方法。甚至只要写findByName这样一个接口方法，他就能智能的帮你执行根据名称查找实体类对应的表数据，完全不用写SQL。
但是，JPA对于多表关联查询以及动态SQL、自定义SQL等非常不友好。对于JPA来说，一种实现实现方式是QueryDSL，实现的代码是下面这样的。我想问：你希望用这样的代码代替SQL么？




JPAQueryFactory queryFactory = new JPAQueryFactory(em);

JPAQuery<Tuple> jpaQuery = queryFactory.select(QTCity.tCity,QTHotel.tHotel)

                                .from(QTCity.tCity)

                                .leftJoin(QTHotel.tHotel)

                                .on(QTHotel.tHotel.city.longValue().eq(QTCity.tCity.id.longValue()));

//添加查询条件

jpaQuery.where(predicate);

//拿到结果

return jpaQuery.fetch();

另一种方法是使用NativeQuery，我仍然想问：你希望在java代码里面用拼字符串的方式写SQL么？




@Entity

@NamedNativeQueries(value={

        @NamedNativeQuery(

                name = "studentInfoById",

                query = " SELECT * FROM student_info " 

                        " WHERE stu_id = ? ",

                resultClass = Student.class

                )

})

@Table(name="student_info")

以上的这部分实现还没有考虑到动态SQL的问题，如果考虑到动态SQL，写法会更复杂。所谓的动态SQL就是：根据传入参数条件的不同，构造不同的SQL，很多的比较这两个框架的文章都忽略了动态SQL的问题，这方面Mybatis支持的更好。Mybatis写的动态SQL说到底还是SQL，而不是java代码或者java代码拼字符串。程序员特别排斥几件事：

将复杂关联关系的SQL写在java代码里面，拼串书写不方便
SQL是最能表达实体关系查询的语言，程序员不希望使用异化SQL语言。
程序员不希望学习不通用的东西，显然SQL大家都会
JPA虽然将大部分操作封装起来了，也挺好用的，但是SQL调优怎么做？

可以使用Spring-Data-JPA-extra解决JPA的拼串书写和SQL异化的问题。但是根据笔者的使用情况，Spring-Data-JPA-extra是一个个人开发者项目，用于生产还很不成熟，对于多数据源处理、复杂类型处理等还有很多的问题。

二、劣币驱逐良币？

然而，另外有一派观点，你看人家国外的程序员怎么都用JPA？你不去学习新东西，还不让别人用？JPA使用很方便啊，唯一缺点就是复杂关联SQL支持差一点,但是只要你学一下也还可以支持啊，你们这是劣币驱逐良币。如果经过很好的实体关系模型的设计，JPA显然是最优解，程序员写的SQL还真不如JPA根据实体关系生成的SQL。笔者要说，这种观点也是有道理的。但是，笔者要说并不是国内程序员不愿意学习，而是另有原因。