91 thoughts on “javaer 们, JPA 和 mybatis,喜欢用哪一个

  1. JPA+1,维护过其他人的 mybatis 项目,业务也挺简单的,但逻辑大部分都放在了 sql 里,简单的功能一下复杂得一匹( sql 烂一定是我的错)

  2. 喜欢用 mybatis,集成 mybatis plus,舒服的一批,想写 sql 就写 sql,不想写就 warpper 查询,也很方便,但是 jpa 就不行了,遇到联表查询 就残废

  3. 一张列表页面 有很多条件需要查询 java 怎么办 不使用类似 elasticsearch
    是不是一堆
    if( key exists request) query.and(Model.key= value)

  4. mybatis + mybatis plus ,公司用了 jpa,然后遇到统计是真的难受,mybatis plus 使用上感觉和 jpa 差不多了,还是喜欢 mybatis

  5. JPA 简单查询用方法名查, 联表或者复杂查询直接 @Query 手写 sql, 返回复杂对象的时候写个 interface

    感觉 mybatis 麻烦多了

    看了一下同事使用 mybatis pagehelper 的方式, 自己接受不了

    喜欢手写 sql, 不管啥语言框架都一样的使用方式

  6. mybatis + mybatis-plus 这一类东西, 不知道楼上说 mybatis 有问题是有啥问题?

    jpa 多表查询难用..

  7. JdbcTemplate 加模仿 ActiveRecord 写了个简单的 ORM 。

    简单 SQL 用 ActiveRecord ORM 一波,复杂的用 JdbcTemplate 手写 SQL

  8. @KarlChen2015 #5

    我觉得相反,应该是性能要求越高业务约简单的场景用 mybatis 更好。 那种复杂业务动不动几千上万张表的系统,mybatis 关联都要写吐

  9. @Yechs 用 mybatis plus,增加属性很方便呀,简单对象,只用改实体。至于其他需要手写 sql 的地方,你用其他方式也肯定要改 sql 语句的。

  10. @BBCCBB XML 拼 SQL 体验太差了,相比写代码而言

    没有少写代码,SQL 还是那个长度
    没有提高性能,增加了解释 XML 的开销
    代码和逻辑分离,不利于读旧代码
    降低了灵活性,某些场景下还很麻烦

    现在 mybatis 有点几年前 ssh 那味儿

  11. @sagaxu 但写代码拼 sql 更麻烦呀. 像 mybatis 的 where, set 等标签能解决里面一个条件都不成立却多了一个 where, set 语句这种问题. 拼代码有点麻烦.
    像 mybatis-plus 这种解决了大部分场景, 剩下的就是用 xml 或者注解写 sql 搞定.

  12. 一开始功能简单的时候 jpa 可以节省开发时间,但我觉得如果项目规模慢慢扩大,对于复杂的报表需求又不得不用 mybatis 。所以为什么不干脆一开始就选用 mybatis 呢?

  13. @sagaxu
    @a719031256

    现在都是这种注解写法吧……

    @Results({@Result(property = “detail”, column = “detail”, javaType = Object.class, typeHandler = JsonTypeHandler.class)})
    @Select(“<script>select a.id, e.`name` as entity, a.type, a.`code`, a.`name`, a.balance, a.detail, a.is_invalid ” +
    “from iaf_account a join iab_entity e on e.id = a.entity_id where e.tenant_id = #{tenantId} ” +
    “<if test = ‘key != null’>and (type = #{type} or `code` = #{key} or name like concat(‘%’,#{key},’%’)) </if>” +
    “order by created_time desc</script>”)
    List<AccountDto> getAccounts(QueryDto dto);

    压根不需要 xml

  14. 项目用的 spring-data-mongo, 其中 CRUD 方法、分页排序、方法名的查询、注解条件甚是方便、SpringData 系列互通,人生苦短何不一试。

  15. @rockyou12 query dsl 代码生成每次都需要手动触发 compile, 这个怎么弄?而且为了少数查询需求生成这么多代码感觉有点重

  16. 简而言之,面相对象和面相过程的 PK
    简单业务逻辑,写到 service 中,选哪个无所谓
    复杂业务逻辑,想要 ddd,选 jpa

  17. QueryDSL 会受到 Entity 里的 OneToOne,OneToMany 封注解得影响,有时候 left join 变 cross join,大家咋解决的?不写导航属性么

  18. 我宁可用 spring jdbctemplate 也不想用 jpa,项目中用过要多难受有多难受。jpa 擅长的自然好写,jpa 不擅长的实现起来就想撞墙,所以对我而言 jpa 并不是一个可以放心全部托付的框架。现在许多 mybatis 二次开发的框架单表也不用写 sql 了,同时具有 jpa 的简单和 mybatis 的灵活,不香吗?

  19. 话说楼主提到的这个 mybatis-dynamic-sql 有点意思,有 mybatis-plus 等库的感觉了,而且是官方出的,关注了

  20. 咱自有国情,mybatis 可以自己定制 SQL 业务逻辑,只不过太多逻辑冗余进去,特别复杂特别久远 SQL 代码都不敢碰,改一点就缺点东西多点东西出来,甚至部分条件失效。
    JPA 没怎么用过,听过名字,在想会不会是那种 hibernate 的继承者的啥的,也不好说啥。

  21. 我选择在 SpringBoot 里引入 JFinal 的 Record 模块,Db.use(“A 库”).find(“select * from XX where DATA_DT=?”,’20200926′);

    做报表时,这个写法太舒服了

  22. 多数 hibernate,少数 mybatis-plus
    喜欢继承 mp 的 interface,简单的用 baseMapper 的查询,复杂的注解写 SQL 。整体比 h 省心且直观。
    不喜欢 mp 的 @Select 语句无法变色高亮检查,code review 会坑。

    另外 mp generate 的 entity 结构竟然不是标准 JPA 规范的,很烦。

发表评论

电子邮件地址不会被公开。 必填项已用*标注