Java 都这么多年过去了，生产级别数据库操作库除了 JPA 和 Mybatis 还有什么？ JPA 和 mybatis-plus 比优势在什么地方？

[pigbug]

[BBCCBB]

@yema50 Wrapper 统一放到响应 Service 里. 不要用到的地方到处写..

[Rwing]

欢迎各位大佬来 C# 体验一下 entity framework，看看什么是真正的 ORM

[abcbuzhiming]

@yema50
方式 1 就是传统的 mybatis 方法，你要用方式 1，没必要用 mybatis-plus

方式 2 本身就是脱胎于 ActiveRecord 的链式调用，这个方式最初的来源就是我上面说的 Ruby on Rails,它提供了高度的灵活性，代价的就是代码看上去像事务脚本，但是我认为这个在开发效率，这是值得的。

最后，后端的项目，在经历过几轮微服务拆分后，业务是高度内聚的，你几乎很难遇到多处复用你这个查询代码的情况，我认为初期就考虑复用，这个想法是有问题的

[Cbdy]

[abcbuzhiming]

@Kipp
@BBCCBB
我明确的反对这个想法，QueryWrapper 本质就是 ActiveRecord，把它直接放在最靠近业务的地方才是对的，硬要封装起来啦就又变成了 JPA 的思路，那还不如用 JPA 。

你要追求灵活性，你就要失去一些结构上的严谨，以及代码感觉看上去像事务脚本

你要追求严谨性，你的代码就要封装套层，失去灵活性。

我选择灵活性，ActiveRecord 的诞生就是为了灵活而不是为了严谨性，要严谨的面向对象的话，选 JPA

[pigbug]

@abcbuzhiming #25 非常赞同

[ikas]

1.ORM 到底是什么程度..根据业务.喜好选择,根本不是什么需要争论的问题
2.如何更好的拼接 SQL[条件]才是最大的问题,不管你用 jpa,spring jdbc,jdbc,mybatis,dsl
3.xml 只是 mybatis 的一种动态 sql 方式.他本身也支持代码,也支持你自己开发其他动态方式,也支持 sqlbuilder

目前我自用的....
@Select("""
<script>
select
count(*)
from
pet
<where>
<if test='name != null' > and name like #{name}</if>
</where>
</script>
"""
)
List<Long> querySomeCount(@Param("name") String name);

[ColinZeb]

@abcbuzhiming 不考虑一下 EF Core 的 Linq

[micean]

@yema50

为何不直接在 controller 里构造 QueryWrapper 呢？
见过太多怪物 service 了

[yema50]

@micean controller 里加业务逻辑感觉有点奇怪吧

[abcbuzhiming]

@ColinZeb 用过，linq 很好用，但是还是那句话，复杂查询最后你还是会回到 SQL 上来的


@yema50 没啥怪的，看你选严谨还是选灵活，我自己的项目就经常在 Controller 层加业务

[potatowish]

jdbctemplate 就算了吧，最好的方案就是单表操作用 mbp 、tk，多表操作就在 mybatis xml 中写原生的 sql，无脑吹这个那个的都是老顽固

[ccppgo]

@yema50 第一种方式没有任何意义

[wanguorui123]

C#的 EntityFramework 、FreeSql，才是真正的 OOP

[paouke]

@yema50 我一般会吧 wrapper 查询的部分封到一个 localservice 里面

[yema50]

@paouke 然后在需要使用的地方注入 localservice 并调用 localservice 封装的方法吗

[hutoer]

@abcbuzhiming Controller 层加业务？不考虑业务代码复用？

[EKkoGG]

@Rwing #22 真的！最近在学习 mybatis-plus，要被气哭了，EF Core+ LINQ 可以称为绝杀

[ColinLi]

简单查询用 jpa，复杂查询用 jdbctemplate+sqlbuilder

[ebony0319]

ORM 的方向是对的,但是 jpa 在稍微复杂一点的场景,关联表的时候还是得写原生 sql,革命尚未成功,仍需努力.