好奇 Java mybatis 能火是不是因为 Java 编译器对多行文本的扫码解析不友好?

举个 c#的例子

```code
var table="";
string Sql =String.Fomat(@"
select
* from
{0}
",table)
```
这样子就可以了。

而在 java 里写 Sql 模板 sting Sql= "" + "" + ,或 append() ,非常令人难受。。

不是，xml 是麻烦，但是强约束，强约束意味着开发之后少麻烦

比起 MyBatis ，我更喜欢用 Doma2

Java 代码：
var str = """
    i
    am
    multiline
""";

年轻人还是太年轻，见过和写过的 SQL 太幼稚，才会质疑 mybatis 的能力

@potatowish #29 多表可以用 MyBatis Plus Join 。

在复杂的点不想写 XML 或者在 Mapper 定义的话，可以使用 MyBatis Plus 的 SqlRunner 来处理

不是，它火是因为动态 SQL 拼接的方式在当时是独一份。至于多行字符串，mybatis 的 SQL 一般是写在 XML 配置文件里面的，跟 Java 多行字符串表达式没关系。

有 mybatisplus 是不是没必要再用 jpa 了，单表上代码，多表 xml

扪心自问，拼接的方式最后的结果是什么，就是变成一坨根本没办法维护的、看一次要几分钟甚至几十分钟才能完全看懂的 SQL ，像牛皮癣一样贴在那里， 里面还藏了各种变量拼接。

@chendy 这位说的在理，搞 jpa 那一套要对面向对象建模有比较深刻的理解，本质上是先有表再有对象，还是先有对象再有表的问题，难度在于对象建模和关系建模不匹配，jpa 要把 hibernate 那一套搞清楚，真的有难度。

统计报表的 sql 不用 xml 直接写 sql 太蛋疼了，动不动就关联十几张表，巨多的字段。 要是用 mybatis-plus 这种一个一个单表查出来在 service 层拼接数据，那维护和调试起来真是血压拉满，有些功能直接用 sql 的功能函数实现方便的多得多。反正最终目的都是为了完成业务需求，没必要用折磨自己的方式来做，怎么快 怎么简单怎么来。xml 还有个好处就是 线上环境 sql 有问题可以直接去线上环境修改文件不用编译 这点挺方便的