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

[pigbug]

[abcbuzhiming]

@hutoer 为什么要在初期就考虑代码复用？为啥不能遇到能复用的时候，再去把代码抽成 service ？为啥一定在初期搞这种过度设计？

[abcbuzhiming]

@ebony0319 ORM 的方向如果是对的，它就不会遇到复杂场景必须回到 SQL 这种尴尬的问题。本质是对象模型并不能如当初的人们估算的那样取代关系模型，只要关系模型自身不倒，ORM 就始终处于尴尬的位置

[alamaya]

@abcbuzhiming 可怕，连考虑代码复用都成了过度设计，好同情接手你的屎山代码的同事

[abcbuzhiming]

@alamaya
问题是你到底是怎么考虑代码复用的？

哦，看到一段操作数据库的代码，就不能放在 Controller 里？就得写个 service 装起来，搞不好这个 service 还得先是一个接口，然后做出一个 Impl 实现类来？是这个意思吗？

考虑复用难道不是先考虑一下有没有复用的可能性吗？当根本就没有复用的可能性时，就像我前面说的，业务代码几轮拆分后都是高内聚的，哪有让你复用的机会？也要“复用”吗？

如果你一开始就已经想到了这段代码在业务上就是需要复用的，甚至这个需求就在眼前，那我万分支持你把立刻把这段代码抽出来变成一个 service，给人复用。如果你一开始根本想不出来要在哪里复用，那为什么要复用？这不是过度设计又是什么呢？就像很多项目写一堆直到项目死掉都不会改成实现的接口，美其名曰 [规范] 。。。

退一万步讲，你到了遇到有需要复用的那一天，再把 Controller 里的代码抽出来变成一个复用的 service，这很费事吗？

我见了太多的人，都是嘴上空谈说 [复用] ，我直接问他们关于眼前项目，你觉得这个位置的代码在哪里可能会复用？鲜有答上来的，他们大部分也估不到项目在发展中会遇到什么。只不过是看别人是这么干的，或者说按所谓的规范应该这么干的。。。

除非你已经想到需要的地方，那么再动手，不要过早动手，优先完成业务。这是我的法则。就目前的实践经验看，和我配合的人都挺喜欢的，没觉得我的代码就是屎山。当然有人不认同我能理解，毕竟张口闭口设计规范的人非常之多，谢欢在项目里写一堆到死也不会发生变化的接口的人更不少

[paouke]

@yema50 是的

[Kamiyu0087]

进来想说 Exposed
仔细一想 Exposed 是 Kotlin 的

[testFor]

有个疑问,jpa 这种的 orm,不是对于领域设计会更加友好么,不是更能解决复杂业务么

[fpure]

上个项目用 JPA，想撞墙，因为 JPA 匮乏的表达能力做了很多骚操作，现在代码也已经腐烂的不成样子了

[SawyerGuo]

哎，我也听说 mybatis-plus 好用，但就是懒得学。

[fpure]

@abcbuzhiming 很多人就是这样，过度设计，滥用 DRY 原则和开闭原则

[witcherhope]

@testFor 领域驱动设计跟 ORM 没有任何必然联系，统一语言做的就是屏蔽技术细节，抽象业务本身。

[potatowish]

@SawyerGuo 没有学习成本，照着文档撸就好了

[Lemeng]

哎，感觉自己人变懒了

[KevinBlandy]

spring-data-jpa + querydsl 永远滴神。

[shakoon]

脱离业务场景谈技术都是空谈。——一个写了十几年存储过程的程序员

[crclz]

JPA for write/transaction
SQL for query

=================

“来自”微软官方的答案。


——引号是因为微软在.net 世界给出了一个类似的解决方案。
https://docs.microsoft.com/en-us/dotnet/architecture/microservices/microservice-ddd-cqrs-patterns/cqrs-microservice-reads

查询（ read ）用的是 micro orm Dapper，命令（ write ）用的是宇宙最强 orm Entity Framework 。

虽然 ef 的表达能力几乎覆盖 sql，但是微软却告诉你：没必要全程用 ef 哦！

关键词：cqrs

[fkdog]

我觉得 mybatis-PLUS 的 api 设计的一言难尽。一种查询方法愣是被弄出 N 个 api 。。
其实大部分人对 orm 框架的需求很简单，支持泛型 crud 模板方法，支持 orm 就足以，一个简单的 DBUtils 工具类就能实现。

现在国内的互联网项目都普遍喜欢在代码层面 join 而不是交给数据库。类似管理后台这种经常需要复杂条件组合查询和多表 join 的，一般都丢交给 es 或者数仓了。

[yizmaoaa]

Ebean

- -哎，主要还是多行字符串，不然谁用 Mybatis

[ameccc]

SQLDelight 能算是生产级别的吗？自己写玩具用这个写的很开心。

[GiantHard]

我最近在从 mybatis-plus 切换到 MyBatis Dynamic SQL，好处如下：

* 类型安全，通过官方提供的代码生成器，保证数据模型与数据库模型一致，避免字段写漏、类型写错
* 表达力强，Dynamic 提供的 DSL 语法与 SQL 相比差异不大，完全可以复用自己写 SQL 的经验
* 足够灵活，不管是简简单单的 INSERT 还是像一篇小作文一样的 WHERE，Dynamic 提供的 DSL 都可以 hold 住
* 拓展性强，Dynamic SQL 并没有跟 MyBatis 绑定死，默认还支持 JDBCTemplate 跟 JDBC，除此之外，还可以自定义类型安全的数据库函数跟操作符

最开始我很喜欢 EF Core 这样“正宗”的 ORM，但是现在用过这种类型安全且表达力强的 SQL DSL 之后，我的初心动摇了