现在 Mybatis 是更多使用注解还是 XML 进行配置？

xml 是 mybatis 的优势 如果用 mybatis 不用 xml 无疑是自费武功，注解方式有更好的选择

注解比 XML 先进

结合吧，不复杂注解，复杂 xml

kotlin+注解

xml 有个 p 的优势

其实我觉得是看习惯，我习惯了 xml，就不想写注解，然而有的人习惯注解，就不想写 xml
这东西，我实在找不出先进不先进的差距
难道执行效率上有差异？

xml 更繁琐,复杂的语句用注解简直是灾难

这还用选吗，当然是 JPA 啊

简单的增删改查用 Mapper[https://github.com/abel533/Mapper/wiki]自动化生成,复杂的使用 XML 进行编写。
XML 有两个功能我们使用比较多。
1.引用 SQL 片段。
2.自定义标签语义，实现一些高级功能。
另外 Java 注解写 SQL 是用字符串拼起来的，不好看也不好修改，我们现在使用的 java8 还不支持 ` ` 反单引号的多行字符串。

我以前也是用ｘｍｌ，然后注解，再后来ＪＰＡ

复杂查询 XML，可以在 SQL 编辑器格式化好代码后直接粘贴过来，更易读，方便大家。如果是简单查询，用 JPA 更方便。所以我觉得 mybatis 注解基本没什么优势。

这个看情况，如果全是单表查询，那就使用注解（一般都是些 mybatis 的插件），不用 xml，如果涉及到多表查询，还是得用 xml，而 xml 自己手写配置比较累，可以用逆向工程来构建，然后自己再向 xml 中写自己的 SQL ；

MyBatis Generator

我习惯在 xml 中配置，不把配置打到包里面，这样改 sql 就不需要重新打包部署了

一楼说 xml 是 mybaits 的优势…啥优势啊

有意思，之前有类似的问题，可以看下或许有收获
现在用 mybatis 都不用 xml 了吗
t/541755

复杂 sql 使用 xml 还是有优势的，尤其遗留业务系统,因为 sql 过长过复杂，使用注解并不够清晰，也可以把 xml 中的 sql copy 到数据库查询工具中一边查询，这样方便理解业务和 debug.遗留系统一般业务较重而且基本是面向数据库编程为指导思想来设计的，所以 mybatis 适合这类系统。

你想象一下 上百行 sql 写在注解里面是一种什么样的体验

用通用 mapper 实现基础得增删改查 复杂得直接 xml

@ghos 的确，看来还是我遇到的问题偏简单了

@pelloz @coang 这种方式不错，感谢

@blackboom Spring Data JPA 听到很多次推荐了，学习一波

复杂查询用注解的你们开心就好。如果业务简单就用 JPA 了也不会用 mybatis 注解。用 xml 并不丑，java 里写 sql 才是真的丑。

这种怎么用注解啊

当然是配合使用，那种容易理解的一行就能搞定的就注解，复杂点的就 xml

@ahmcsxcc #23 这个复杂的 sql 你咋写的.. 配置下 IDEA 的数据库就可以做自动补全了 https://www.jianshu.com/p/d997d278813c

如何提升 mybatis 开发的效率，可以试试 https://github.com/gejun123456/MyBatisCodeHelper-Pro IDEA 插件

这都说的是啥

正确答案是, 看团队习惯, 定下来了之后大家统一用一种.

@gejun123456 #25
专门的 DBA 写的

interface OneMapper: AnyMybatisPluginMapper<Entity> {

@Select("""
1. Idea inject language -> xxxSQL
2. 配置数据库，用于 auto complete
3. 开始写复杂 sql
""")
fun querySomething(): List<Entity>

}


等 jdk13 出来了，多行字符串都有了，xml 这种早该丢了

去年底的一个小项目尝试了下注解，难用到爆，回头再用 XML，真香

自动生成的不动，自己增加的用注解，省的数据库增加字段重新生成需要整理 xml

当然是根据业务来啊，那些报表类的 你用注解不是给自己找刺激吗？

@ahmcsxcc SelectProvider

经常跳槽用注解，否则用 xml。

@ghos
SelectProvider 了解一下？利用反射还可以生成基本的 SQL 语句

@Macolor21 sql 没自动提示，用起来没有 xml 方便

@micean 我们这里还大量使用 jdk7，少部分用 8，我感觉就算 jdk 升级到 20，我们这里依然是 7。。。有多少公司是追着 jdk 新版在用的？

这个看团队吧 ，目前在用 xml

出于对 xml 的厌恶和偏见，一般用注解+Provider 的形式

@NoKey
kotlin-stdlib 支持 6 以上
j 调用 k 即可

Mybatis-plus 这个 mybatis 增强框架不错。
简单的 sql 我用注解。
涉及多表或者复杂条件的用 xml。
不过大部分 mybatis-plus 的 QueryWrapper 都可以搞定。

简单的查询就直接用 Mybatis-Generator 生成的 Mapper 搞定，复杂的 SQL 语句都是用 xml

把 sql 这种声明式语言糅杂到代码里让人无法忍受，即便是使用 chain call，也觉得是在破坏代码的简洁美感。

@ahmcsxcc 写这种 SQL 的人先拖出去抽一顿，想不开么？

肯定是注解

@ahmcsxcc 为什么不拆分

@ahmcsxcc 不觉得这样写就不对吗

需要复杂 sql 和 resultmap 我选择 xml,简单 sql 返回 pojo 直接注解，mapper 中的每个接口方法打好注释

xml 有什么优势？ xml 能干的注解基本都可以 再不济二者也可混用