精华内容
下载资源
问答
  • 这个demo同时整合了springboot+JPA+mybatis这个两个orm框架。
  • Spring集成JPA和MyBatis简单例子
  • 浅谈jpa和mybatis区别

    千次阅读 2020-02-28 15:27:24
    作者:唯有努力不欺人丶 ... ...来源:简书 著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。...mybatis和jpa,两个持久层框架。从底层到用法都不同。但是实现的功能是一样的。所以...

    作者:唯有努力不欺人丶
    https://www.jianshu.com/p/32ce87c163d6
    链接:https://www.jianshu.com/p/32ce87c163d6
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    其实要承认,一个东西用久了都会有习惯心理。mybatis和jpa,两个持久层框架。从底层到用法都不同。但是实现的功能是一样的。所以说一直以来颇有争议。常年混迹于各大qq技术交流群。见过jpa的死忠粉也见过mybatis的铁杆。作为一个不到两年工作经验的小菜鸟来说,你让我分析源码,讲什么底层实现我是讲不出来的。只能作为一个使用者,来谈谈自己对这两个框架的理解。

    首先,都知道jpa的前身是著名的ssh中的h——>Hibernate。我到现在还记得学习Hibernate时对它产生的讲解:一个希望不用写sql语句来操作数据库的懒到愿意为此开发一个框架的创始人,其实也够奇葩到值得记住了。而现在的jpa,我觉得主旨也确实在贯彻这个理念。你要承认,jpa的对于单表的简单查询确实简单方便又实用。但是同时,对于多表关联和复杂查询,起码目前为止,要么把复杂查询拆成多个简单查询,要么宁可直接一个nativeQuery = true来原生查询。如果这两点都没能满足你业务的需求,我不敢下定结论说你的设计有问题,但是如此复杂的业务逻辑,身为小白的我实在无法给你建议了。

    然后说到mybatis,原谅我入行时间比较晚。从我开始学习java他就已经出现了。听说过他前身好像是ibatis,但是具体就不太了解了。使用上来讲,在那个boot还没有发布的年代,mybatis也曾经是每个程序员必备的基本技能。刚接触的时候mapper映射在我眼中简直是神奇。也算是用了半年多,多少有一定的了解。在这里基本的使用就不多介绍了,反正我一直所应用的也基本都是crud。没到多高深的地步。只能说对于多表查询确实是比较支持。尤其是在业务逻辑多是多表关联的情况下,mybatis绝对比jpa要更加适合。无论是以后的维护还是业务的变更都方便不少。

    可能我这么说大家还是不太理解什么时候用jpa什么时候用mybatis。我举个例子:现在业务上A,B,C,D四个表。如果你每个表都会在业务中用到,都需要有单独的增删改查,虽然有一定的关联关系,但是这种情况用jpa就比较合适。ABCD四个java实体不说,每个实体要对应一个repository。然后再repository层进行crud的编写。但是如果业务上A,B,C,D四个表。这四个是关联关系,你几乎不会单独对A,B,C进行操作,而且展现出来的也是D,那么这个时候jpa的使用就会很麻烦,因为你还是要四个实体四个repository。在一个接口中四个repository挨个调用一次。虽然也能完成业务逻辑,但是复杂又麻烦。还要考虑原子性什么的。所以这个时候用mybatis比较合适了。

    其实说到这大概对于什么样的业务应该采用哪个在思维上应该有个简单的区分了。不过很多时候很多项目不是能一下子分辨出来属于哪种的。所以还是需要具体判断的。虽然工作才一年多,但是外包让我经历了多个项目的经验告诉我,千万别相信那些所谓的“某某大佬”随便给你的建议。(我是指那些连具体业务都不知道就给你建议jpa好还是mybatis好的那种。如果真的是大佬而且愿意为你的项目深入分析并且给出答案,那还是值得参照的)因为以前有一次在老板给了我一个小项目让我独立完成的时候我选择了咨询群里的大佬。记得很清楚当时大佬给的意见就是mybatis。还说了mybatis的好多优点。然后我就自然而然的用了。结果嘛,大家能想到我一个人能完成的项目会有多小,业务多简洁。虽然用mybatis也做完了。但是现在想想,要是换成jpa肯定会更加快速方便的开发。我讲这段经历绝对没有别的意思,只是想告诉大家业务怎么样还是自己最清楚。很多时候我们的询问可能不是很全面,所以别人给的建议也不是很合适。

    然后还有一些额外的东西。比如说spring家族的态度。我不知道各位有没有跟我一样的大众心理。一个jar包。只要是org.springframework.boot这个分组的,就比较信赖。毕竟有那么庞大的家族做后盾呢而且boot真的是封装的越来越具体了~反正依稀记得以前spring创建个项目,还要配置这个那个的,偶尔马虎下还报个错。一个结构要搭好一会儿的(也可能是我当时比较菜,但是确实要配置一些东西)而现在呢,spring boot,差不多创建了,依赖导一下就可以跑。真的是相当方便。方便到前一段时间群里一个小孩子问了一个spring 配置的问题,我居然觉得有点想不起了spring boot用多了,都把人用成sb了~~~哈哈,开玩笑的,别当真。反正现在代码的高度封装让我们用什么都更加简单了。而boot对jpa的封装,反正我个人是觉得在单纯的配置上面,除了在配置文件中连接下数据库然后添加个data-jpa的依赖,搞定了就。这也是个人比较喜欢jpa的一点。部署是真的简单。而且官方文档还很全面。也在持续维护更新。我觉得单纯从spring的角度,jpa就值得一试。当然了,这个属于个人心态,但是如果是新手在自己做练手项目的时候,我还是推荐jpa。

    对了,再额外安利一下,这个就涉及到了个人的使用经验。以前只有mybatis有代码生成器,所以基于这个原因有一段时间我还比较喜欢用mybatis。但是现在jpa也有了代码生成器。从表到实体和从实体到 表都可以自动生成的。小白们别手敲啦~~~(ps:是因为我以前做过这种事所以在此提醒一下跟我一样白的小盆友,知道的可以掠过)。至于代码生成器的使用,只要你知道了这个概念去百度都能找到用法,在这里我就不多说了。实在不知道的也可以问我,我要是看到了会回的,虽然我觉得找我不如自己百度呢。

    然后再说个题外话,其实jpa和mybatis都是很有必要学的。因为遇到的项目会各种各样,所以两者各有长短。还有就是如果自己没话语权的时候,最好上级让用啥就用啥。注意!我说的是最好。如果说你们team氛围比较好,然后领导比较愿意接受意见什么的,你出与实际考虑确实有不同的意见可以提出来。不然的话还是老老实实听指挥吧。别管你以为有多不合理。我不是在宣扬什么消极理念。而且在一个team中领导所考虑的可能和你考虑的点不一样。或者说你知道的不太全面等。没必要非要为了所谓的自己为正确然后最后弄的大家都不愉快。尤其是最后还可能结果也不会想你想的那样。大家都是做技术的,有点自视清高或者说自己的见解很正常。但是切记人还是要谦卑。给大家讲一个实际发生的故事。

    我们team一直是手写接口文档,然后人工维护的。确实现在有很多文档生成工具,我自己也用过swagger做过demo,但是团队里有的人不会用,而且其实维护起来也很麻烦(可能是没用习惯的麻烦,这不是主要的),而且我们公司接的项目都比较小。所以领导说就手工维护接口文档吧。然后前一段时间来了个实习的小孩,可能是学习确实很努力,接触的技术很多。然后一开始整天也干劲儿满满的自觉加班在公司学习到很晚那种。后来开了个项目,小孩看到我们手工维护接口可能是觉得比较low,所以跟我们领导建议用swagger。然后我们领导就很委婉的说他回去了解了解,考虑考虑再说,先这么手工维护吧。然后自那以后我们再手动改接口,他就会讲这样怎么怎么,巴拉巴拉的。重点是有一次我们team中工作时间比较久的一个大哥因为接口对接没对接好,所以测试的时候有点小bug,这个孩子又开始抱怨说用手写文档怎么怎么不好。。然后我们领导就爆发了,劈里啪啦一顿训斥,大概意思就是这里的人谁不比他有经验啊,他优越什么啊,之所以不改是因为要前端后端都要熟悉这个框架,没必要。。然后那以后这个小孩沉默多了,也不知道是顿悟了什么还是说生气。后来不久这个小男孩就走了。辞职还是被劝退也都不知道。其实单单从这个故事看,一个swagger的事,说不上谁对谁错的。非要说的话,我们一个外包公司,肯定是需求对付做完就行了,老板不愿意拿时间来让员工学习一些没必要的技能。从小男孩的角度,一个实习生没有决定权却非要坚持主见。这个也算是职场经验了 吧~说着说着跑题了~

    反正核心几句话“:

    1,jpa和mybaits各有优缺点。

    2,使用哪个合适要结合具体的业务进行分析。

    3,当你没有决定权的时候,最好领导让用什么用什么。

    对于咱们技术人员来讲,两个都要熟悉,会用。

    喏,手打不易,大家动动小手分享转发点赞评论啥的~~~~

    作者:唯有努力不欺人丶
    链接:https://www.jianshu.com/p/32ce87c163d6
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    展开全文
  • ​​​​​首先,Spring Data JPA可以理解为 JPA 规范的再次封装抽象,底层还是使用了 Hibernate 的 JPA 技术实现。 JPA默认使用hibernate作为ORM实现,所以,一般使用Spring Data JPA即会使用hibernate。...

    ​​​​​首先,Spring Data JPA可以理解为 JPA 规范的再次封装抽象,底层还是使用了 Hibernate 的 JPA 技术实现。

       JPA默认使用hibernate作为ORM实现,所以,一般使用Spring Data JPA即会使用hibernate。Hibernate是一个开放源代码的对象关系映射框架,它对JDBC进行了非常轻量级的对象封装,它将POJO与数据库表建立映射关系,是一个全自动的orm框架,hibernate可以自动生成SQL语句,自动执行,使得Java程序员可以随心所欲的使用对象编程思维来操纵数据库。

       MyBatis 是一款优秀的持久层框架,它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息,将接口和 Java的enetity对象映射成数据库中的记录。

    所以,这里说 jap和mybatis的区别也就是 hibernate和mybatis的区别了。

        Mybatis学习门槛低,简单易学,程序员直接编写原生态sql,可严格控制sql执行性能,灵活度高,非常适合对关系数据模型要求不高的软件开发,例如互联网软件、企业运营类软件等,因为这类软件需求变化频繁,一但需求变化要求成果输出迅速。但是灵活的前提是mybatis无法做到数据库无关性,如果需要实现支持多种数据库的软件则需要自定义多套sql映射文件,工作量大。

       Hibernate对象/关系映射能力强,数据库无关性好,对于关系模型要求高的软件(例如需求固定的定制化软件)如果用hibernate开发可以节省很多代码,提高效率。但是Hibernate的学习门槛高,要精通门槛更高,而且怎么设计O/R映射,在性能和对象模型之间如何权衡,以及怎样用好Hibernate需要具有很强的经验和能力才行。

    总结来说:

       Mybatis可以进行更细致的SQL优化,查询必要的字段,但是需要维护SQL和查询结果集的映射。数据库的移植性较差,针对不同的数据库编写不同的SQL。

       Hibernate对数据库提供了较为完整的封装,封装了基本的DAO层操作,有较好的数据库移植性。但是学习周期长,开发难度大于Mybatis。

    对于hibernate和mybatis而言,两者都是orm框架,就一定会有对比。两方,网上都是各抒己见

    比如:

       从框架的设计理念上来看,hibernate是一种面向对象,全自动的orm框架,hibernate 是我们不用关注数据库,而需要去关注代码本身,通过操作映射表的实体对象,一定程度上简化了开发,提高了开发效率,而mybatis 是一种半自动的orm框架,使用时需要自己写sql语句,在我看来,项目中太多的sql语句,反而不如直接的实体对象操作更清晰明了

         从表关联上看,有人说hibernate的多表关联是一大弊病,hibernate 本身并没有提供实体类多表关联的方法,而如果通过mangtoOne之类的实体类设计又会产生效率问题,但其实现在已经有了很好的解决方案,通过整合queryDSL就可以很方便地对表对象进行关联查询,这样其实mybatis 的灵活sql优势其实也没有那么的明显

         从表,表字段映射上看,hibernate 直接通过框架生成表,表字段,能够更方便地对数据库的表进行维护,而mybatis 建表更新表都需要写sql语句,又需要花费精力去维护这样的sql语句,sql语句查询出来的数据又要通过resultMap 进行映射,没有hibernate方便

         从性能上看,如果只是内部系统,用户量较小的系统,两个框架其实性能上差距不会太明显,这个时候推荐使用springdatajpa 开发效率反而会更高

       总之,按照用户的需求在有限的资源环境下只要能做出维护性、扩展性良好的软件架构都是好架构,所以框架只有适合才是最好。其次就是领导的决策和team的沟通!

    参考:https://www.jianshu.com/p/22f75d68deca

     

     

     

    展开全文
  • JPA Mybatis 的争论由来已久,还记得在 2 年前我就在 spring4all 社区就两者孰优孰劣的话题发表了观点,我当时是力挺 JPA 的,这当然跟自己对 JPA 熟悉程度有关,但也有深层次的原因,便是 JPA 的设计理念契合了...

    前言

    JPA 和 Mybatis 的争论由来已久,还记得在 2 年前我就在 spring4all 社区就两者孰优孰劣的话题发表了观点,我当时是力挺 JPA 的,这当然跟自己对 JPA 熟悉程度有关,但也有深层次的原因,便是 JPA 的设计理念契合了领域驱动设计的思想,可以很好地指导我们设计数据库交互接口。这两年工作中,逐渐接触了一些使用 Mybatis 的项目,也对其有了一定新的认知。都说认知是一个螺旋上升的过程,随着经验的累积,人们会轻易推翻过去,到了两年后的今天,我也有了新的观点。本文不是为了告诉你 JPA 和 Mybatis 到底谁更好,而是尝试求同存异,甚至是在项目中同时使用 JPA 和 Mybatis。什么?要同时使用两个 ORM 框架,有这个必要吗?别急着吐槽我,希望看完本文后,你也可以考虑在某些场合下同时使用这两个框架。

    ps. 本文讨论的 JPA 特指 spring-data-jpa。

    建模

    @Entity
    @Table(name = "t_order")
    public class Order {
      
      @Id
      private String oid;
      
      @Embedded
      private CustomerVo customer;
      
      @OneToMany(cascade = {CascadeType.ALL}, orphanRemoval = true, fetch = FetchType.LAZY, mappedBy = "order")
      private List<OrderItem> orderItems;
    }
    

    JPA 最大的特点是 sqlless,如上述的实体定义,便将数据库的表和 Java 中的类型关联起来了,JPA 可以做到根据 @Entity 注解,自动创建表结构;基于这个实体实现的 Repository 接口,又使得 JPA 用户可以很方便地实现数据的 CRUD。所以,使用 JPA 的项目,人们很少会提到”数据库设计“,人们更关心的是领域建模,而不是数据建模。

    <generatorConfiguration>
        <context id="my" targetRuntime="MyBatis3">
          
          <jdbcConnection driverClass="com.mysql.jdbc.Driver" connectionURL=""
               userId="" password=""/>
    
          <javaModelGenerator targetPackage="" targetProject="" />
    
          <sqlMapGenerator targetPackage="" targetProject="" />
    
          <javaClientGenerator targetPackage="moe.cnkirito.demo.mapper" />
          
          <table tableName="t_order" domainObjectName="Order" />
    
    
        </context>
    </generatorConfiguration>
    

    Mybatis 用户更多使用的是逆向工程,例如 mybatis-generator 插件根据如上的 xml 配置,便可以直接将表结构转译成 mapper 文件和实体文件。

    code first 和 table first 从结果来看是没有区别的,差异的是过程,所以设计良好的系统,并不会仅仅因为这个差异而高下立判,但从指导性来看,无疑设计系统时,更应该考虑的是实体和实体,实体和值对象的关联,领域边界的划分,而不是首先着眼于数据库表结构的设计。

    建模角度来看,JPA 的领域建模思想更胜一筹。

    数据更新
    聊数据库自然离不开 CRUD,先来看增删改这些数据更新操作,来看看两个框架一般的习惯是什么。

    JPA 推崇的数据更新只有一种范式,分成三步:

    先 findOne 映射成实体
    内存内修改实体
    实体整体 save
    你可能会反驳我说,@Query 也存在 nativeQuery 和 JPQL 的用法,但这并不是主流用法。JPA 特别强调”整体 save“的思想,这与领域驱动设计所强调的有状态密不可分,即其认为,修改不应该是针对于某一个字段:”update table set a=b where colomonA=xx“ ,而应该反映成实体的变化,save 则代表了实体状态最终的持久化。

    先 find 后 save 显然也适用于 Mybatis,而 Mybatis 的灵活性,使得其数据更新方式更加地百花齐放。路人甲可以认为 JPA 墨守成规不懂变通,认为 Mybatis 不羁放纵爱自由;路人乙也可以认为 JPA 格式规范易维护,Mybatis 不成方圆。这点不多加评判,留后人说。

    从个人习惯来说,我还是偏爱先 find 后整体 save 这种习惯的,不是说这是 JPA 的专利,Mybatis 不具备;而是 JPA 的强制性,让我有了这个习惯。

    数据更新角度来看,JPA 强制使用 find+save,mybatis 也可以做到这一点,胜者:无。

    数据查询
    JPA 提供的查询方式主要分为两种

    简单查询:findBy + 属性名
    复杂查询:JpaSpecificationExecutor
    简单查询在一些简单的业务场景下提供了非常大的便捷性,findBy + 属性名可以自动转译成 sql,试问如果可以少写代码,有谁不愿意呢?

    复杂查询则是 JPA 为了解决复杂的查询场景,提供的解决方案,硬是把数据库的一些聚合函数,连接操作,转换成了 Java 的方法,虽然做到了 sqlless,但写出来的代码又臭又长,也不见得有多么的易读易维护。这算是我最不喜欢 JPA 的一个地方了,但要解决复杂查询,又别无他法。

    而 Mybatis 可以执行任意的查询 sql,灵活性是 JPA 比不了的。数据库小白搜索的最多的两个问题:

    数据库分页怎么做
    条件查询怎么做

    Mybatis 都可以轻松的解决。

    千万不要否认复杂查询:如聚合查询、Join 查询的场景。令一个 JPA 用户抓狂的最简单方式,就是给他一个复杂查询的 case。

    select a,b,c,sum(a) where a=xx and d=xx group by a,b,c;
    
    

    来吧,展示。可能 JPA 的确可以完成上述 sql 的转义,但要知道不是所有开发都是 JPA 专家,没人关心你用 JPA 解决了多么复杂的查询语句,更多的人关心地是,能不能下班前把这个复杂查询搞定,早点回家。

    在回到复杂数据查询需求本身的来分析下。我们假设需求是合理的,毕竟项目的复杂性难以估计,可能有 1000 个数据查询需求 JPA 都可以很方便的实现,但就是有那么 10 几个复杂查询 JPA hold 不住。这个时候你只能乖乖地去写 sql 了,如果这个时候又出现一个条件查询的场景,出现了 if else 意味着连 @Query 都用不了,完全退化成了 JdbcTemplate 的时代。

    那为什么不使用 Mybatis 呢?Mybatis 使用者从来没有纠结过复杂查询,它简直就是为之而生的。

    如今很多 Mybatis 的插件,也可以帮助使用者快速的生成基础方法,虽然仍然需要写 sql,但是这对于开发者来说,并不是一件难事。

    不要质疑高并发下,JOIN 操作和聚合函数存在的可能性,数据查询场景下,Mybatis 完胜。

    性能
    本质上 ORM 框架并没有性能的区分度,因为最终都是转换成 sql 交给数据库引擎去执行,ORM 层面那层性能损耗几乎可以忽略不计。

    但从实际出发,Mybatis 提供给了开发者更高的 sql 自由度,所以在一些需要 sql 调优的场景下会更加灵活。

    可维护性
    前面我们提到 JPA 相比 Mybatis 丧失了 sql 的自由度,凡事必有 trade off,从另一个层面上来看,其提供了高层次的抽象,尝试用统一的模型去解决数据层面的问题。sqlless 同时也屏蔽了数据库的实现,屏蔽了数据库高低版本的兼容性问题,这对可能存在的数据库迁移以及数据库升级提供了很大的便捷性。

    同时使用两者
    其他细节我就不做分析了,相信还有很多点可以拿过来做对比,但我相信主要的点上文都应该有所提及了。进行以上维度的对比并不是我写这篇文章的初衷,更多地是想从实际开发角度出发,为大家使用这两个框架提供一些参考建议。

    在大多数场景下,我习惯使用 JPA,例如设计领域对象时,得益于 JPA 的正向模型,我会优先考虑实体和值对象的关联性以及领域上下文的边界,而不用过多关注如何去设计表结构;在增删改和简单查询场景下,JPA 提供的 API 已经是刻在我 DNA 里面的范式了,使用起来非常的舒服。

    在复杂查询场景下,例如

    包含不存在领域关联的 join 查询
    包含多个聚合函数的复杂查询
    其他 JPA 较难实现的查询
    我会选择使用 Mybatis,有点将 Mybatis 当做数据库视图生成器的意味。坚定不移的 JPA 拥趸者可能会质疑这些场景的存在的真实性,会质疑是不是设计的漏洞,但按照经验来看,哪怕是短期方案,这些场景也是客观存在的,所以听我一言,尝试拥抱一下 Mybatis 吧。

    随着各类存储中间件的流行,例如 mongodb、ES,取代了数据库的一部分地位,重新思考下,本质上都是在用专业的工具解决特定场景的问题,最终目的都是为了解放生产力。数据库作为最古老,最基础的存储组件,的确承载了很多它本不应该承受的东西,那又何必让一个工具或者一个框架成为限制我们想象力的沟壑呢?

    两个框架其实都不重,在 springboot 的加持下,引入几行配置就可以实现两者共存了。

    我自己在最近的项目中便同时使用了两者,遵循的便是本文前面聊到的这些规范,我也推荐给你,不妨试试。

    零基础学习Java,推荐个人Java学习园地

    展开全文
  • mybatis和jpa,两个持久层框架。从底层到用法都不同。但是实现的功能是一样的。所以说一直以来颇有争议。常年混迹于各大qq技术交流群。见过jpa的死忠粉也见过mybatis的铁杆。作为一个不到两年工作经验的小菜鸟来说,...

    其实要承认,一个东西用久了都会有习惯心理。mybatis和jpa,两个持久层框架。从底层到用法都不同。但是实现的功能是一样的。所以说一直以来颇有争议。常年混迹于各大qq技术交流群。见过jpa的死忠粉也见过mybatis的铁杆。作为一个不到两年工作经验的小菜鸟来说,你让我分析源码,讲什么底层实现我是讲不出来的。只能作为一个使用者,来谈谈自己对这两个框架的理解。

    首先,都知道jpa的前身是著名的ssh中的h——>Hibernate。我到现在还记得学习Hibernate时对它产生的讲解:一个希望不用写sql语句来操作数据库的懒到愿意为此开发一个框架的创始人,其实也够奇葩到值得记住了。而现在的jpa,我觉得主旨也确实在贯彻这个理念。你要承认,jpa的对于单表的简单查询确实简单方便又实用。但是同时,对于多表关联和复杂查询,起码目前为止,要么把复杂查询拆成多个简单查询,要么宁可直接一个nativeQuery = true来原生查询。如果这两点都没能满足你业务的需求,我不敢下定结论说你的设计有问题,但是如此复杂的业务逻辑,身为小白的我实在无法给你建议了。

    然后说到mybatis,原谅我入行时间比较晚。从我开始学习java他就已经出现了。听说过他前身好像是ibatis,但是具体就不太了解了。使用上来讲,在那个boot还没有发布的年代,mybatis也曾经是每个程序员必备的基本技能。刚接触的时候mapper映射在我眼中简直是神奇。也算是用了半年多,多少有一定的了解。在这里基本的使用就不多介绍了,反正我一直所应用的也基本都是crud。没到多高深的地步。只能说对于多表查询确实是比较支持。尤其是在业务逻辑多是多表关联的情况下,mybatis绝对比jpa要更加适合。无论是以后的维护还是业务的变更都方便不少。

    可能我这么说大家还是不太理解什么时候用jpa什么时候用mybatis。我举个例子:现在业务上A,B,C,D四个表。如果你每个表都会在业务中用到,都需要有单独的增删改查,虽然有一定的关联关系,但是这种情况用jpa就比较合适。ABCD四个java实体不说,每个实体要对应一个repository。然后再repository层进行crud的编写。但是如果业务上A,B,C,D四个表。这四个是关联关系,你几乎不会单独对A,B,C进行操作,而且展现出来的也是D,那么这个时候jpa的使用就会很麻烦,因为你还是要四个实体四个repository。在一个接口中四个repository挨个调用一次。虽然也能完成业务逻辑,但是复杂又麻烦。还要考虑原子性什么的。所以这个时候用mybatis比较合适了。

    其实说到这大概对于什么样的业务应该采用哪个在思维上应该有个简单的区分了。不过很多时候很多项目不是能一下子分辨出来属于哪种的。所以还是需要具体判断的。虽然工作才一年多,但是外包让我经历了多个项目的经验告诉我,千万别相信那些所谓的“某某大佬”随便给你的建议。(我是指那些连具体业务都不知道就给你建议jpa好还是mybatis好的那种。如果真的是大佬而且愿意为你的项目深入分析并且给出答案,那还是值得参照的)因为以前有一次在老板给了我一个小项目让我独立完成的时候我选择了咨询群里的大佬。记得很清楚当时大佬给的意见就是mybatis。还说了mybatis的好多优点。然后我就自然而然的用了。结果嘛,大家能想到我一个人能完成的项目会有多小,业务多简洁。虽然用mybatis也做完了。但是现在想想,要是换成jpa肯定会更加快速方便的开发。我讲这段经历绝对没有别的意思,只是想告诉大家业务怎么样还是自己最清楚。很多时候我们的询问可能不是很全面,所以别人给的建议也不是很合适。

    作者:唯有努力不欺人丶
    链接:https://www.jianshu.com/p/32ce87c163d6
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

    然后还有一些额外的东西。比如说spring家族的态度。我不知道各位有没有跟我一样的大众心理。一个jar包。只要是org.springframework.boot这个分组的,就比较信赖。毕竟有那么庞大的家族做后盾呢而且boot真的是封装的越来越具体了~反正依稀记得以前spring创建个项目,还要配置这个那个的,偶尔马虎下还报个错。一个结构要搭好一会儿的(也可能是我当时比较菜,但是确实要配置一些东西)而现在呢,spring boot,差不多创建了,依赖导一下就可以跑。真的是相当方便。方便到前一段时间群里一个小孩子问了一个spring 配置的问题,我居然觉得有点想不起了spring boot用多了,都把人用成sb了~~~哈哈,开玩笑的,别当真。反正现在代码的高度封装让我们用什么都更加简单了。而boot对jpa的封装,反正我个人是觉得在单纯的配置上面,除了在配置文件中连接下数据库然后添加个data-jpa的依赖,搞定了就。这也是个人比较喜欢jpa的一点。部署是真的简单。而且官方文档还很全面。也在持续维护更新。我觉得单纯从spring的角度,jpa就值得一试。当然了,这个属于个人心态,但是如果是新手在自己做练手项目的时候,我还是推荐jpa。

    对了,再额外安利一下,这个就涉及到了个人的使用经验。以前只有mybatis有代码生成器,所以基于这个原因有一段时间我还比较喜欢用mybatis。但是现在jpa也有了代码生成器。从表到实体和从实体到 表都可以自动生成的。小白们别手敲啦~~~(ps:是因为我以前做过这种事所以在此提醒一下跟我一样白的小盆友,知道的可以掠过)。至于代码生成器的使用,只要你知道了这个概念去百度都能找到用法,在这里我就不多说了。实在不知道的也可以问我,我要是看到了会回的,虽然我觉得找我不如自己百度呢。

    然后再说个题外话,其实jpa和mybatis都是很有必要学的。因为遇到的项目会各种各样,所以两者各有长短。还有就是如果自己没话语权的时候,最好上级让用啥就用啥。注意!我说的是最好。如果说你们team氛围比较好,然后领导比较愿意接受意见什么的,你出与实际考虑确实有不同的意见可以提出来。不然的话还是老老实实听指挥吧。别管你以为有多不合理。我不是在宣扬什么消极理念。而且在一个team中领导所考虑的可能和你考虑的点不一样。或者说你知道的不太全面等。没必要非要为了所谓的自己为正确然后最后弄的大家都不愉快。尤其是最后还可能结果也不会想你想的那样。大家都是做技术的,有点自视清高或者说自己的见解很正常。但是切记人还是要谦卑。
    反正核心几句话:

    第一、jpa是对象与对象之间的映射,而mybatis是对象和结果集的映射。

    第二、jpa移植性比较好,不用关心用什么数据库,因为mybatis自由写sql语句,所以当项目移植的时候还需要改sql。(及时判断数据库类型,不嫌累么)。

    第三、当需要修改字段的时候mybatis改起来特别费事,而jpa就相对简单。

    第四、如果用hibernate学习起来比较费时间,而mybatis相对来说比较简单,也可以用springdata,但个人觉得springdata只适合单表。(缓存方面暂不考虑)

    对于咱们技术人员来讲,两个都要熟悉,会用。

    *喏,手打不易,大家动动小手分享转发点赞评论啥的~~~~*

    在这里插入图片描述

    展开全文
  • Spring Data JPAMybatis区别

    万次阅读 2019-06-08 00:58:03
    Spring Data JPA可以理解为 JPA 规范的再次封装抽象,底层还是使用了 Hibernate 的 JPA 技术实现。 MyBatis本是apache的一个开源项目iBatis, 2010年这个项目由apache software foundation 迁移到了google code,...
  • SpringBoot2集成JPA和MyBatis

    千次阅读 2018-12-01 18:55:28
    JPA和MyBatis各有各的好处,混合食用效果更佳。 根据前面的博文《Spring Boot2集成JPA《SpringBoot2集成MyBatis》,我们已经知道怎么分别集成JPA和MyBatis,两者一起集成也简单。 合并配置文件application.yml ...
  • JPAMybatis区别

    千次阅读 2021-03-03 14:42:07
    其实JPA和mybatis大体上没什么区别,架构上很相似,mybatis就是mapper层,JPA就是repository层,其他都一样的 JPA就是把mapper层的接口换成repository的接口: 那么接口具体长什么样呢? mapper层 自己写sql语句 ...
  • JPA Mybatis 技术选型

    2021-06-22 13:45:39
    JPA Mybatis 如何进行技术选型? 下面看看大精华总结如下: 最佳回答 首先表达个人观点,JPA必然是首选的。 个人认为仅仅讨论两者使用起来有何区别,何者更加方便,不足以真正的比较这两个框架。 要评判...
  • Springboot JPAMybatis区别

    千次阅读 2020-07-09 11:26:52
    其实JPA和mybatis大体上没什么区别,架构上很相似,mybatis就是mapper层,JPA就是repository层,其他都一样的 mybatis的层次结构看这里 JPA就是把mapper层的接口换成repository的接口: 那么接口具体长什么样呢? ...
  • 谈谈JPA和Mybatis的优缺点

    千次阅读 2020-08-31 08:58:29
    1.什么是JPA JPA是一种规范,它简化了现有持久化的开发,并且充分吸收了Hibernate、TopLInk、JDO等框架。SpringData JPA是全自动框架,不需要自己写sql,当然也可以自己写sql实现。而自动生成sql这点是优点,也是缺点...
  • 谈谈SpringData JPA和Mybatis的优缺点

    千次阅读 2020-07-15 20:48:04
    Mybatis Mybatis是一种半自动的ORM框架,它简单易上手,没有第三方依赖,支持对象与数据库的ORM关系映射,将sql代码与业务代码分离,使得开发人员可以更自如的写出高效的sql,不过反过来说不像SpringData JPA这种全...
  • 面试之jpa和mybatis区别

    万次阅读 2018-01-25 14:55:39
    第一、jpa是对象与对象之间的映射,而mybatis是对象结果集的映射。 第二、jpa移植性比较好,不用关心用什么数据库,因为mybatis自由写sql语句,所以当项目移植的时候还需要改sql。(及时判断数据库类型,不嫌累么...
  • SpringBoot+Hibernate Jpa和Mybatis和Mybatis Plus的注解模式使用对比对照对比三种数据库持久层框架的JPA1、导包2、添加配置3、添加web依赖(方便测试|可选)4、实体层(model|pojo|entity)5、DAO层(repository)6...
  • mybatis并没有jpa功能,建表语句还是要自己写的。 spring data jpa是全自动框架,不需要写任何sql。而mybatis是半自动框架,需要自己写sql,mybatis-plus为mybatis赋能,使其也可以基本上不需要写任何模板sql。 ...
  • Spring集成JPA和MyBatis例子

    万次阅读 2017-05-16 21:50:35
    Spring JPA MyBatis
  • Spring集成JPA和MyBatis简单例子
  • Spring Data JPAMyBatis对比

    万次阅读 多人点赞 2018-10-29 11:36:31
    使用Spring Data,使得基于“repositories”概念的JPA实现更简单容易。Spring Data JPA的目标是大大简化数据访问层代码的编码。作为使用者,我们只需要编写自己的repository接口,接口中包含一些个性化的查询方法...
  • JPA的优缺点大概就是有基本的CURD接口提供使用,实现简单,但是多表查询的时候要返回自定义的实体去接收就有点麻烦。mybatis的优点就是可以定制自己的sql语句,自由度大,多表查询的时候多复杂的语句只要在数据库里...
  • spring boot mvc 基本配置请参考前面的博客 ...https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#reference 项目结构如下: 1、在pom.xml添加依赖 <dependency> ...
  • Jpa VS MyBatis,你用哪个?

    千次阅读 2019-05-05 08:05:30
    经常看到有小伙伴在讨论 JPA MyBatis 这两个孰优孰劣的问题,其实松哥觉得这是一个伪命题,没必要为这种问题争个面红耳赤,每种框架有它存在的道理,也有各自擅长的...
  • Spring4集成JPA和MyBatis3简单例子
  • 核心都是将关系型数据库数据转成对象型。当前流行的方案有Hibernate与myBatis。两者各有优劣。竞争激烈,其中一个比较重要的考虑的地方就是性能。因此笔者通过各种实验,测出两个在相同情景下的性能相关的指数,供...
  • jpamybatis混用导致程序卡死

    千次阅读 2019-05-14 14:47:34
    这两条查询的区别就是,一条是jpa去查的,一条是mybatis去查的. 我在把jpa的查询改成mybatis的查询(sql相同)发现就不会出现卡死问题. 问题解决了,但是为什么jpamybatis在同一个方法中一起使用会出现卡死的问题...
  • 作者:华华luckywww.jianshu.com/p/3927c2b6acc0Spring Data JPA是Spring Data的子模块。使用Spring Data,使得基于“rep...
  • ![图片说明](https://img-ask.csdn.net/upload/201711/21/1511249051_492763.png) 一运行就报这个,我不用jpa,就使用mybatis没问题。
  • 据传闻:连接池作者是《星球大战》迷,C3P0就是其中的一个机器人,并且这个名称中包涵connection pool的单词字母。因此叫这个名字。 C3P0就是下图中的右边的那个机器人。左边是他哥哥R2D2。 一、JPA 概述 1...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 26,886
精华内容 10,754
关键字:

jpa和mybatis的区别