Java 社区除了 mybatis 之外，有没有类似.net 下的 Dapper？

[bbsfoo]

先说一下为什么不用 mybatis，主要是觉得太复杂，太累赘，特别是 SQL 语句的拼接。
平时项目规模很小，最多十来个表就搞定了，ASP.NET MVC，数据库也很单一，一律为 Oracle，Dapper+SQL 简单粗暴高效。

现在想转到 Spring Boot，但这个 ORM 的问题卡住了，大家都说好的 mybatis 太难用，特来请教，有没有类似 Dapper 的工具？

[Rwing]

从软件工程的角度来讲，Dapper 和 mybatis 这类 sql helper 都是不利于可维护性的。所以，最好找个强类型的纯粹的 orm，：）

[abcbuzhiming]

@Rwing ORM 可维护？我这么说吧，想用对象模型取代关系模型从根子上就是错的，关系模型要是能被对象模型描述的话，那现在流行的就该是对象数据库而不是关系数据库。只要你的系统里有关系数据库，你就得面对 sql，或者其实你压根就不需要关系数据库，不如拿掉直接上 nosql。无论怎样，

[chenuu]

没有用过 Dapper,但是真的没人用 jpa/hibernate 了吗?

[Rwing]

@abcbuzhiming 是的，我也认同你说的对象模型和关系模型是不能完全匹配的。但是，基于这个现状，我们只能期望从 orm 的层面解决这个问题。纯 sql 显然不是更优的解决方案。

[Mmiracle110]

不想写 SQL 的话，可以考虑 data-jpa

[qq1004108488]

mybatis 难用？？？？？
第一次听到说 mybatis 难用的，随便去慕课网找个免费视频就能入门了，上手不用 2 小时。
简单的直接用 MybatisPlus 调函数调用，复杂的直接写 sql 或者 xml，不知道哪里说的难用。

[abcbuzhiming]

@qq1004108488 虽然我一直推崇直接面对 sql，并且也在 java 生态圈里待了很久，但是有人如果说 mybatis 难用，我是赞成的，mybatis 真的是一点都不好用，只要去看看别家同样是 sql 优先的库你都不会觉得 mybatis 好用，而且我认为用 xml 保存 sql 是个败笔。太容易出错了，程序员不得不消耗更多心智负担来解决 xml 中的 sql 出错问题。

[q397064399]

@abcbuzhiming #26
主要为了这个诉求再发明一个 DSL 不值得

1. ORM 封装过度 JPA + QueryDSL 这种是最吼的，封装非常彻底，适合 DDD 复杂的领域建模
基本上不用写 SQL，出了性能问题最难排查， 有一个对应的 HQL 可以裸写，但是这个技术非常小众，用的人少


2.Mybatis 裸写党 + 插件增强党，这种最原始，性能全掌控在程序员手里，
但是效率低，维护起来非常麻烦，国内由于阿里系最早就是 Mybatis 搞起来的，所以大多都是这种原始方式，
很多公司是禁用 Mybatis 的级联功能的，一对多 多对多 全都是代码维护的，工作量极大，代码量小的时候还可以
代码量大的时候，有很大一部分代码就是在组装数据结构。


总而言之没有什么银弹，还是要根据你的项目实际来，如果是业务非常复杂，需要领域建模，JPA + QueryDSL 目前是首选，如果业务非常简单，那就是怎么快，怎么来，反正后期维护基本上不是首要考虑的事情，在国内基本上这就是实际情况。

[qq1004108488]

@abcbuzhiming 你说的别家是指同语言还是不同语言？同语言来说，除了 jpa 就是 mybatis，我不认为在一个持续迭代的项目中，jpa 会比 mybatis 简单，单单多表间的依赖关系，在设计实体类的时候，就已经足够麻烦了。
如果不同语言的话，抱歉，我没用过其他语言操作数据库。不提供意见，而且也没有可比性。
至于 xml 保存 sql 容易出错问题，我只能说，基本没遇到过，因为 idea 有对应的提醒，而且有插件也可以直接根据数据库表生产 xml 文件，只是表关联的关系在 xml 实体类与数据库字段需要自己再添加一下对应关系，这个在官方文档也有很详细的说明和例子。
其实最不需要消耗心智的数据库交互，那肯定就是传统的 jdbc 直接写 sql 字符串了，而且这个 mybatis 同样也支持不用 xml，直接通过注解的方式直接写 sql。但是说真，这个出错才是最难排查的。而且如果涉及到动态判空，会比 xml 更加麻烦。
当然，跨语言如果有超级强超好用的数据库操作库，是可以用服务的方式，专门设计一个数据库交互的服务，java 服务用 RPC 或者 HTTP 的方式调用该其他语言数据库交互服务，这个在大公司大型项目中，并不少见。毕竟，这种大型项目，一般开发者是不会甚至没权限直接操作数据库的。

[qq1004108488]

@q397064399 其实在 mybatisPlus3.0 里面，也是可以不用写 sql 或者 xml 了，直接用 lambda 的方式查数据库。现在很多人其实还是在用原始的眼光看待 mybatis。Mybatis 已经升级换代很多了。

[fuckshit]

spring-jdbc 啊。

[q397064399]

@qq1004108488 #29 国内的情况还是重业务，代码质量跟技术升级 都是次要的，没用上新的很正常，mybatis-plus 这个插件 估计也就 2 年不到的历史吧，我司的项目 最早的项目都是 7 年前的玩意了，想一下改变太难。

[gowk]

为什么我劝你放弃 mybatis: https://zhuanlan.zhihu.com/p/45044649
我同意文章中的大部分观点

[zazalu]

emmmm，还好吧？ 我用过 hibernate 和 mybatis，准备试试 mybatis-plus. mybatis 我在使用过程中感觉比较恶心的是二级缓存的 namespace 问题。。。 其余配置都已经有了成熟的自动生成插件或者说逆向工程，感觉已经不是特别复杂了。

[yiyi11]

别争了，不用 mybatis 的人都是幸福的，用 mybatis 的人都是不幸的。不幸不是因为用了 mybatis，而是 mybatis 更适合。最终结论甚至是换公司。
有用的建议:mybatis 推荐 2 种方案，1.通用 mapper+pagehelper，2.mybatis-plus。个人喜欢第一种，因为 pagehelper 的分页跟 mapper 方法逻辑上解耦，mybatis-plus 的分页方案跟 mapper 方法耦合。

[guojxx]

nutz-dao

[StarkWhite]

关键词 ORM，嗯，某爬虫可能要来了 /狗头

[qq1004108488]

@gowk 里面的观点，大部分是主观意识加挑刺的，同样的逻辑，放在其他框架一样能挑出一大堆问题，你看点赞数和评论就知道了。我随便挑几点：

6.调试问题／代码重构：mybatis 可以打印执行 sql 日志，直接复制日志即可打开 sql 命令行调试，至于重构，难道其他 dao 框架重构能轻松，这个只能说看业务。

7.手写的 SQL 未必比 hibernate 生成的 SQL 效率高～：未必是什么意思？起码我手写能看出来写的规不规范吧，效率问题更多的是数据库设计问题，执行上的效率，这个只能看每个人对于数据库的理解了。

8.缓存问题～：老实说，我做 java 开发几年了，没遇到过几个需要调缓存的，可能我公司小，项目垃圾吧。

9.分表分库／审计／全文索引问题～：这个是数据库设计问题，拿一个出了 N 年的框架来 PK 一个新生儿，适合？解决方案是要经过迭代经验的。

10.糟糕的实现：不知道他说什么？我的确看到过有说第一代 mybatis 的代码质量比较差，但是看不出什么糟糕的实现。

11.关联查询：关联查询的场景本来就不多，而且基本使用任何框架，都是需要特殊处理的，如果复制场景不需要特殊处理，程序员的价值在哪里？

12。满世界找文件：这个只能说代码分层设计问题，分好职责包和类，有那么麻烦？也可以说是 IDE 问题，用 idea 可以直接插件关联接口类和 xml，直接跳转。真没试过满世界找文件的情况，只能说这个作者根本就是找茬。

1-5 我就懒得说了，打字好累。

现在很多网上的文章，都是站台文章，参考 angular 和 vue 两个团队的争吵。之前还有人说 lombok 不建议用的，现在不都是真香。使不使用一个框架，不是看他的代码有多么优美，不是看他效率有多么高，而是看上手难度和使用成本。很明显大部分公司，在用 mybatis 上的使用成本是很低的。只需要设计好数据库表，实体类和 xml 直接生成，如果使用 tk 或者 mybatisplus 的话，直接 service 都给你生成好了，填充业务逻辑就可以了。这难道不是一个好的优点？至于说追求超级性能的，那还用什么传统数据库，直接大数据那套不是更强。

[qq1004108488]

@q397064399 这就是多个角度问题，我一般会研究主流新的框架，看下能不能在公司或者自己的组里面推广用于下个项目，公司用不用，我不在意，反正作为码农就是完成公司任务就行，但是起码需要对新知识有了解。
不然就会像上周那个帖子一样，说新员工鄙视他用 SpringMvc 还觉得自己不了解 Spirngboot 而感到合理。
新的技术，如果比旧的上手难度高很多，性能差非常多，那肯定是不可能推广成功到我们大伙知道的，能让大伙知道并使用肯定是有其优点的。
至少 mybatis 的优点，目前越来越大于缺点了。