为什么 MyBatis-Plus 不使用 Java Persistence API 的注解?

[echo1937]

最近学习 MyBatis-Plus （看了 2 小时），学到通用 Mapper 这一块时，注意到了实体类的几个注解：
表名注解 @TableName 、主键注解 @TableId 、非主键字段注解 @TableField，
实际上，这几个注解作用和 JPA 的 @Table 、 @Id 、 @Column 功能基本是一样，
粗粗翻了一下 MP，诸如此类的注解还很不少。

按理说，@Table 、 @Id 、 @Column 等注解属于 JPA 规范（现在改名叫 jakarta.persistence-api ），
一般都放在 javax.persistence 的包路径下，属于 JSR-317，JSR-338 规范的内容，
很多持久层框架都支持这个规范，遇到 MyBatis-Plus 这样有自己独立注解的，有点惊讶。

我们的项目一直是 Spring Data JPA 和 MyBatis 一起用，如果要升级成 Spring Data JPA + MyBatis-Plus，
实体类字段就要标上两套注解，看着很是别扭，组员比较排斥这种用法。

这种做法在我看来，好处是避免了引入对 JPA 的依赖，还有其他方面的考量吗？

[rockyou12]

mybatis 本来也不能做类似 @OneToOne 、 @OneToMany 这些级联操作，用自己的 api 能自己把控功能。像你用 Spring Data JPA，很多功能到头来还是要用 hibernate 的包的注解才能实现，所以我觉得差别不大。

[echo1937]

@rockyou12 #1
MyBatis 是可以通过 associateion 标签来进行级联操作的，我们之前也这么做（主要是查询场景），
Spring Data JPA 的话，我们已经很少很少使用 Hibernate 包的注解了，甚至很多时候使用 Hibernate 的注解，
他会提示你使用 JPA 规范的注解，比如以前经常使用 Hibernate 的 @ForeignKey 注解，现在已经 @deprecated，
点进去他提示你：@deprecated Prefer the JPA 2.1 introduced {@link javax.persistence.ForeignKey} instead.

[340244120w]

可能作者有 JPA PSTD，恨屋及乌，所以也才选择了 mybatis~

[haochih]

同比较好奇，按理来说按 JSR 规范统一掉对大家都有好处。不过也说不定人家是想自己定标准呢。/狗头

[handsomezai]

可能是为了中文爱好者使用方便吧，idea 查看源码有中文注释，对我等 CET6 未过的码友甚是友好，mp 的中文注释挺好的

[ChanKc]

语言障碍的客观存在，国人做的很多东西都会忽略掉已有的一些技术标准和规范（通常这些都是英文写的）

[binbinyouliiii]

有建议提 issue

[pushback]

@haochih 自己定标准的结局就和目前前端所谓的百花齐放一个下场。
@echo1937 试试看能不能重写解析器

[rockyou12]

@echo1937 mybatis 级联我确实不知道，但你用 jpa 不太可能定义一种类似 @Type 让所有框架都能兼容。而自定义类型对 orm 框架还是非常重要的，本来规范再好也不可能覆盖所有场景，不管哪个框架总要扩展自己功能。虽然我也觉得 mybatis-plus 是可以兼容 jpa 部分规范的，但人家不想兼容也不是很大问题

[coang]

个人也觉得 mp 自定义注解很怪.. 所以个人选择 tk.mybatis 的辅助框架.. 但是 tk 的框好像没有再更新了.. 功能上也没有 mp 齐全挺可惜的..

[aguesuka]

jpa 的设计理念和 mybaties-plus 的不一样，mybatis-plus 是 DSL to SQL 和 ResultSet to Bean 。而 jpa 是 DSL to Bean 。

jsr 规范并不是金规玉律，比如依赖注入标准 jsr-330，spring 虽然实现了这个标准，不过正常的项目应该没人使用吧。而 orm 远比 ioc 复杂，我总有种萝卜坑的感觉。
mybtis-plus 的代码欠规范也是很大一部分原因。
让 mybatis-plus 使用 jpa 的 bean 也不是不可以，写一个 addJpaEntityToMybatisPlus 应该不太难

[yinzhili]

楼主可以选用 tk mybatis mapper 。它使用的基本上都是 Java Persistence API 的注解。
mybtis-plus 这个项目个人觉得优点和缺点都很明显。看得出来它的开发团队想做的事情太多，这对于一个工具包来说不一定是好事。

[Navee]

这样更有控制权呀~
一方面控制用户，迁移成本高
二方面控制自己的需求，自定义注解更灵活

[CantSee]

mybatis 一把梭