耐久层框架JPA与Mybatis该怎样选型
2019-11-18杂谈搜奇网33°c
A+ A-一、近况形貌
如今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。笔者要说,这类看法也是有原理的。然则,笔者要说并非国内顺序员不情愿进修,而是尚有缘由。
- 起首,笔者终年处置长途事情,与外洋顺序员打仗较多。他们习气运用JPA的一个缘由,真的是因为他们国度的运用范围太小了,比起国内的一个运用动则上百万的用户比拟,他们在数据库设想与调优的需求上明显更自在。
- 外洋的运用设想每每更简约,而国内的运用需求每每功用性更强。假如不信,你能够去看看事情流,什么会签、流程回退什么的都是我们发现的,他们没有。你让他们用JPA写一个我们的事情流运用试一试,累吐血他们也做不到。
- 异化SQL或许代码内里写SQL,肯定水平上增加了进修本钱和运用本钱。所以用的人少,用的人少你就得将就团队中的大部份人。
说完以上几点,Mybatis为何在国内会有云云多的运用者及运用厂商就不难理解了。Mybatis还能够运用如:Mybatis-plus或许代码自动生成来填补易用性上的不足。JPA的身体、家室、性情样样都是满分,就是脸长得磕碜点难以处置惩罚交际关联。Mybatis虽然说在各方面都不优异,身体还能够、样貌也还说得过去、性情也还好。关键是你说什么都听你的,尚有情愿帮他化装的朋侪。要你说你选哪个?
那末,有的人会说,你这是抬杠?外洋就没有受众数目多、功用性强的互联网运用了么?生怕比国内还多吧,这个也是现实。然则从比例上讲照样国内更多,比例决议开辟人员挑选手艺的方向。这也致使了一个惯性头脑,他们日常平凡就用JPA进修练习,所以写大型效劳运用的时刻也用JPA。那末,他们写JPA会写庞杂SQL么?答案是很少会用到,以至有的外洋公司就明令禁止写关联查询SQL。那怎样办?不必关联SQL怎样开辟营业需求?不会啊。
三、效劳拆分或微效劳
国内如今也有愈来愈多的公司,举行微效劳的落地,但是真正落地比较好的企业少之又少。这和多表关联查询有什么关联?我们先来完成如许一个需求:查询属于A角色相干的一切的营业B数据。
- 假如我们开辟的是传统的单体运用,我们多是把角色表A和营业表B举行关联查询,然后获得查询效果
- 假如我们做的是微效劳,我们多是拆分为权限效劳A、营业效劳B。先去接见A效劳接口猎取角色标志信息,然后再依据角色标志信息去营业效劳B接口猎取营业数据。
那末有的人会说,接见两个接口肯定比接见一个接口更慢吧!这个真的不是,假如我们做微效劳,肯定是我们的运用范围及数据量抵达了肯定水平。也肯定会斟酌分表分库、负载平衡、效劳拆分细化等题目,当分布式的开辟体式格局被运用越多,多表关联查询运用的时机也就越少。拆分后的效劳因为功用单一、负载分流等缘由,接见速率每每比大数据量数据集合存储、多效劳集合布置的运用会快许多。
题目回来了,不必关联SQL怎样开辟顺序?总的来讲就是经由过程合理的效劳拆分、运用的界面数据的组织关联的合理的设想,团队具有比较好的微效劳落地履历,是能够完成不运用关联查询SQL开辟运用的。人人也晓得,NOSQL愈来愈盛行,绝大部份的NOSQL数据库都没有所谓的关联关联。
四、框架对照选型
对照项 | Spring Data JPA | Mybatis |
---|---|---|
单表操纵体式格局 | 只需继续,代码量少少,异常轻易。而且支撑要领名用关键字生成SQL | 能够运用代码生成东西或Mybatis-Plus等东西,也很轻易,但相对JPA要弱一些。 |
多表关联查询 | 不太友爱,动态SQL运用不够轻易,而且SQL和代码耦合到一同 | 友爱,能够有异常直观的动态SQL |
自定义SQL | SQL写在注解内里,写动态SQL有些费力 | SQL能够写在XML内里,是誊写动态SQL语法利器。也支撑注解SQL。 |
进修本钱 | 略高 | 较低 ,基础会写SQL就会用 |
总结一下笔者的看法:
- 假如你是本身开辟“小而美”的运用,发起你运用JPA
- 假如你是开辟大而全的企业级运用,固然要顺从团队的手艺选型。这个手艺选型在国内通常是Mybatis。
假如你们公司的治理异常范例,微效劳落地履历也异常成熟,能够斟酌在团队项目中运用JPA。罕用或不必关联查询。
期待您的关注
- 博主近来新写了一本书:《手摸手教您进修SpringBoot系列-16章97节》
本文转载说明出处(必需带衔接,不能只转笔墨):字母哥博客。