javaer 们， JPA 和 mybatis，喜欢用哪一个

jpa+1, 手上项目对数据库要求不高, 还有 h2 的, 毕竟省事.

简单查询 example 搞定

个人喜欢用 JPA，工作用 Mybatis

JPA + 1

业务越大 Mybatis 越好用

jpa

不对，应该说是 JPA 加 QueryDSL
实话实说，我个人讨厌 mybatis楼下大神们莫要喷我，个人看法

mybatis 恶臭，只剩中国人在用了

打算试试 jooq

jpa，项目里没有太复杂的查询

jpa 越 java 越好

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

只用 jdbctemplate 的同学有没有？

JPA

jpa+mybatis，简单查询 jpa，复杂查询统计 mybatis

JPA+1 , 代码量工作量最少

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

mybatis-plus 香的一批 单表和 jpa 一样 复杂直接写 sql 奴我直言 其他都是辣鸡

工作用 mybatis，我个人来说更喜欢 jpa，mybatis 的 xml 简直让人发疯

pagehelper + Mapper 更好

jpa + jdbctemplate，mybatis 就是辣鸡

两个一起用

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

mybatis+1
单表操作直接 mybatis plus
多表查询自己写 xml

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

我选择用 SQLAlchemy ...（走错片场了

mybatis..
@tinyuu 这两个没有更新了 准备转 mybatis plus

JPA 联表确实是别扭的一 P

简单 jpa，复杂 mybatis

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

感觉 mybatis 麻烦多了

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

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

jooq：我这么没有排面的啊？

spring data jdbc

JPA 没有用过，不过 mybatis 这东西确实头疼。

JPA

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

jpa 多表查询难用..

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

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

@KarlChen2015 #5

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

简单小项目 JPA，大点的 mybatis

mybatis 一改表结构就真的恶心了

？通常都是用 jpa 把表建了就删掉了…然后开始用 mybatis

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

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

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

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

为什么不直接写 SQL ？

这没有喜欢不喜欢吧，看项目实际情况决定，没有哪个更好，只有更合适。

jooq

手写 sql 不香么？

同以上 JdbcTemplate

JPA

@sagaxu 一般的条件 IDEA 插件自动生成 只有很特殊的才要写

能用 JPA 为啥要用 mybatis

@zhady009 idea 插件能自动生成的，JPA 根据接口的方法签名自动合成 SQL 了

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

@BBCCBB 代码手拼也可以封装几个 helper 方法啊，有了 lambda 之后封装简便了很多

@FanError #36 ActiveRecord 是啥？

@gowk +1

@lxk11153 https://javalite.io/activejdbc N 年前 ROR 里的概念

喜欢 JPA ＞ mybatis ＞ mybatis-plus

JPA 加 QueryDSL

jpa+querydsl

@NeverNot 貌似 jpa 也可以直接写 sql 啊 ，@Query 里写联表查询

我在想是不是现在的小朋友都不会写 sql 了 所以 jpa 这种东西才会这么热

mybatis plus

PHP 是最好的语言~~~~~~~

@tydl 兄弟 时代变了 php 要黄了

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

@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

@xuanbg 对 mybatis 来说，没觉得注解和 xml 比起来有什么优势。

jpa+jdbcTemplate

我写过一个项目挺复杂，用的 jdbc

jpa

mybatis-plus，啥也不想，小项目也用这个，总是会出现 sql jpa 搞不了

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

我选择 SQlAchemey...

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

@MarioLuo 我写的时候反正没有需要 compile 的问题，可能因为我项目都是用的 gradle……

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

@18258226728 印象可以这样？@Query(native=true,value="SQL_PLACEHOLDER")

r2dbc 貌似 jpa 友好

jpa

微服务的 cqrs 架构

Jpa + QueryDsl （一年多没用过 mybatis 了）

spring data jdbc + mybatis 这个应该是最佳组合了吧

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

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

不知道为什么我居然没有关注过官方的这个库

都用过，还是觉得 mybatis plus 好用，单表操作用 AR 模式，多表直接写 xml

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

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

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

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

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

ktorm 了解下

jpa querydsl