关于 mybatis 的疑惑

[gomorebug]

新手刚学 mybatis ，发现每次使用都要配一堆层，所以心中有个疑惑，为啥这么麻烦还是有一堆人用？是因为在实践中可以解决啥问题吗

[nothingistrue]

一堆人用，不一定是好用，而往往是没得选。如果你不用 mybatis ，那么剩下的只有两条路：Hibernate ，但是门槛高，不适合国情；啥也不用直接用 JDBC + 手写 SQL ，项目规模稍微超过 「 Hello World 」就更麻烦了。（其实还有 JPA 的其他实现，但是比 Hibernate 门槛更高还不一定有它好用）

上面说得是体系区分，实际应用中，不管是 mybatis ，还是 Hibernate ，直接用都还是更麻烦，还会有上层封装来做可用性提升。像 mybatis 就有 Mybatis Plus （这俩其实是不同开发团队搞的，不应该混为一谈），Hibernate 则是 Spring Data Jpa 。

关于 Hibernate/Jpa 的门槛，需要说一句，它并不只是它们本身的学习门槛，而是设计理念和开发过程门槛：你不一定非要用 DDD ，但一定是拿「实体」或「模型」来作为需求或业务的主要描述语言。

[yohole]

这不是 mybatis 的锅，而是 java 过度设计的锅

[twofox]

JPA 党都是推崇，什么不用写 sql 啦，入手快啦，实在不行我还能写 JPSQL 之类的

但当我真的打算用 JPA 去做企业应用的时候，就难受的一批
你们真的明白一个查询几百行 sql 的感觉吗

是，是可以把逻辑抽取到代码里面执行

我何必啊？大部分都是中间表明细表，我还得单独为这十多个表建 entity ？我只需要为结果负责就可以了，中间的规范并不重要
性能？ Oracle 数据库，硬件继续堆，企业应用又不需要互联网这么高的并发，硬件够我照样能跑

mybatis 还可以做很多 DDL 的骚操作，JPA 用起来就显得麻烦

我自己的项目当然可以按照 JPA 的规范，从头到尾设计的漂漂亮亮，按照开发规范设计
但是按照这样设计之后，遇到复杂的业务逻辑，累的还不是我自己？

sql 一把梭哈，做完项目拿完奖金就改跳槽下家了

还隔这代码规范呢，代码我都想给他混淆再留下来

[shyangs]

以為 JPA / Hibernate 不能裸寫 SQL ，就和用了 jQuery 以為 jQuery 不能混寫 JavaScript 一樣奇葩.

就像 jQuery 會鼓勵你用 jQuery, 因為一旦你裸寫混寫 JS (比如混寫原生 Array.prototype.indexOf ，而不用 jQuery.inArray )，就會失去跨瀏覽器的抽象.

所以 JPA 一樣鼓勵你 JPL, 少用 nativeQuery.

我參與過一個項目用 JPA 相容了三種資料庫，Oracle , SQL Server, MySQL. (因為要部署在客戶的環境，客戶會考慮 DB 價錢.)(裸寫 SQL 就像停留在 ES3 時代，沒跨入 jQuery 時代)

[dif]

JPA 也用过，MyBatis 也用过，目前的业务只有 mybatis 最顺手。

之前做 CMS 的时候，jpa 顺手。

用哪个取决于项目。

[angryfish]

@weijancc 像一些后台管理类的代码，很多是简单的 curd ，不超过 5-10 行的，直接在 controller 写问题不大的，要 controller 与 service 里面跳来跳去更烦。

[Leviathann]

hibernate 搞 dto 之类的很大一部分原因是 entity 是由 hibernate 管理，hibernate 会自动把内存中的 entity 的状态和数据库同步，所以要隔离前端传来的数据和数据库数据

mybatis 搞这么多层是？

[skwyl]

什么一堆层？基础的 mvc 的话 Dao service Controller 还有 对应的 Model （ entity ） entity 就是接收数据库数据映射的。至于其他 VO BO PO DTO 都是出于业务需要增加的

[wanguorui123]

1 、思想：
mybatis 面向过程开发

JPA （ Hibernate ）面向对象开发

2 、侧重点：
mybatis 采用 XML 管理 SQL 比较直观，查询多的场景比较自由灵活、缺点存一些符号冲突（<>），管理思想还是面向过程，需要通过 Plus 加强对象管理

JPA 将数据库完全映射为对象需要有业务的整体设计能力，JPA 优势是简单的 CURD 根本不写 SQL ，JPA 缺点就是需要了解数据状态同步管理，复杂的业务尤其需要了解实体各个阶段状态，以及复杂的连表查询需要调用 JPA 的原生查询接口或者 DSL

3 、抽象能力
mybatis 使用原生的 SQL 方言，迁移能力比较差

JPA 使用 HQL 屏蔽了底层方言差异抽象的比较彻底，迁移能力比较强

[BBCCBB]

你需要被其他 orm 框架教育一下.

[issakchill]

你们真有用过 jpa 写统计报表吗?

[sub166]

@summerLast #39 面向前端也不行，都用 ts 了，然后接口一堆 any ，想想就头大

[Poluk]

@Masoud2023 受教了，老哥，感谢。

[mmdsun]

看了一圈，问下有人用 Spring Data R2DBC 吗？
https://spring.io/projects/spring-data-r2dbc

[aliger]

jpa 坑太多了，直接过滤

[aragakiyuii]

jpa + jdbcTemplate

[tairan2006]

一堆层和 mybatis 没啥关系，纯粹是 java 的一般抽象结构…

而且这个结构其实还蛮合理的，除了 service 必须写个接口算是糟粕。

[dawnflyc]

我也觉得 mybatis 得手写代码，简单的也得手写，虽然 mybatisplus 可以不用手写简单的 sql ，但是限制很大，比如不能连表。
而且我也不懂为什么数据传来传去都得用实体类 哪怕传一个 id 都得用个实体类，在写接口的时候，会接收一些其他的参数，不可能只会出现数据库字段，于是又得扩展实体类。

所以我下定决心开发出了一套库，以上的都改了，我大概描述下：

[xuanbg]

我用 mybatis ，根本不用写任何的 xml 。直接注解写 sql 就行。

[dawnflyc]

@dawnflyc 直接将 sql 相关的语法转换成 java 的那一套，比如 Select(表名).field(字段).where("id",1).and().where("age",">",3).order("time")。大概这样，伪代码展示下，联表的话，join("left","user","order.user_id=user_id")，这样可以避免输入错误。然后也返回 list 和 map ，没有对象那一套，service 传的话，也是需要什么传什么，如果非得实体类 比如一下子传很多，也可以传 然后查询的时候拆了，这块我也没有怎么思考，所以很粗略。