前面一篇sqltoy-orm发版的文章，对mybatis进行了抱怨，客观的说我是希望引起共鸣，如果有质疑则可以通过摆事实讲道理式的逻辑辩论，但大多数人还是不能理解。
对此我表示理解，大多数人都是被mybatis(plus)所熏陶，突然有人如此批判mybatis肯定是难以接受，心里首先想的不是看看内容究竟咋样，而是首先想对文章本人进行攻击(如果不是网络文明用语限制，估计什么的词都能看到)。
事情的起因是最近接触mybatis项目做数据库切换改造，不多讲了，直接上图用事实说话！
其实sqltoy重点想向大家说明的是下图的思想，sqltoy在动态sql编写的方式、可读性、可维护性上应该是
远超mybatis的，这是方向和模式的问题，而不是单纯的技术问题！
看到上面的图我相信一定会有人说：还在sql、还在xml！
我给你补充一下sqltoy从来不搞极端而是一个融合框架，你说的对象化crud、代码中sql、对象化lambda 查询sqltoy都有，那是常识呀朋友，sqltoy是从使用hibernate发展起来的，对象化就是常态化思维呀！
而sqltoy实际上把这些条件隐藏了，变成一种隐式条件，所以看起来简洁，而我在解读时，一样要在脑中把隐式条件加上，实际上分析起来并没有减少负担，反而不熟悉时可能会出错。
实际上动态sql的条件表达式是避免不了的，无论如何变通，哪怕直接写存储过程，sql一样繁琐。mybatis的标签设计，个人认为还是优秀的。
这个“非空”具体要看你的程序的定义，如果是其他逻辑，那么当然是无法隐藏的。
默认空白都转null 的确省去部分 !="" && !=null 的显示条件，这也是你图片示例中，右边sql比mybatis标签表达更为简洁的原因，
这个应该算特殊示例，毕竟通常情况下，条件表达式是复杂多变的， sqltoy也同样需要写条件表达式。
我只是从实用角度上分析两者，暂时未能发现有根本的不同之处。
至于sqltoy的书写方式或习惯是否更好，每个人都有自己的编程习惯，熟悉就可以了
https://gitee.com/redkale/redkale/blob/main/docs/datasource.md
https://gitee.com/redkale/redkale/blob/main/docs/sqlsource.md
1：大厂不需要考虑兼容多数据库，业务发展快，可能还没有做完就砍掉项目了，直接用mybatis，无所谓。tob 企业需要考虑产品多数据库兼容，稳定的模型设计。
2：前后端开发，在大厂不一定前后端人员前后端分开两个人开发，到了中小厂完全变成前后端完全分离，造成质量差，调试成本大，开发效率低。
3：微服务，大厂基础设施完成，每个模块多人维护， 到了中小厂一个人维护几个服务模块。增加不必要的维护成本。