耐久层框架JPA与Mybatis该怎样选型

2019-11-18杂谈搜奇网27°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就会用