数据中台和低代码平台的选型之D-ORM

关于项目中Anyline与MyBatis应用的分析与建议

一、项目背景与工具选择初衷

在项目中为简道云提供后台支持，实现用户自定义数据源生成报表，并汇集金蝶、用友等系统的进销存、财务等数据，这一需求确实带有数据中台和低代码平台的特性。工具选择上，团队未采用MyBatis，而是选用了Anyline，这一决策背后有其考量。

二、Anyline的优势分析

1. ‌动态SQL与多数据库支持‌：

   • Anyline在动态SQL构造和多数据库方言兼容方面表现出色，能够轻松应对复杂查询条件和结果集处理，这是MyBatis在直接使用时难以比拟的。MyBatis虽然强大，但在处理动态SQL和跨数据库兼容性时，往往需要编写大量代码和配置。

2. ‌简化数据计算与处理‌：

   • 在处理数据计算时，Anyline提供了更为灵活和便捷的方式，避免了MyBatis中可能需要的繁琐手工编码。Anyline的设计更贴近程序员的思路，使得数据计算和处理更为直观和高效。

3. ‌低代码与快速开发‌：

   • Anyline的低代码特性使得开发过程更为迅速，能够快速响应业务需求的变化。这对于需要快速迭代和交付的项目来说，是一个重要的优势。

三、MyBatis的局限性

1. ‌查询条件处理复杂‌：

   • 在处理复杂查询条件时，MyBatis需要编写大量的XML配置或注解，增加了开发难度和维护成本。

2. ‌结果集处理繁琐‌：

   • MyBatis的结果集处理需要定义实体类，并在XML或注解中指定映射关系，这在处理复杂结果集时显得尤为繁琐。

3. ‌数据计算需手工编码‌：

   • MyBatis本身不提供数据计算功能，需要手工编写代码进行计算，这增加了开发难度和出错风险。

四、Anyline的文档与社区支持问题

1. ‌文档质量有待提高‌：

   • Anyline的文档确实存在不足，版本更新快导致文档过时，查找困难。这给用户带来了不便，也影响了开发效率。

2. ‌社区支持有待加强‌：

   • 相比MyBatis等成熟框架，Anyline的社区支持可能较弱。在遇到问题时，可能难以找到现成的解决方案或示例代码。

五、建议与展望

1. ‌加强文档建设‌：

   • 建议Anyline团队加强文档建设，及时更新文档内容，提供清晰的查找路径和示例代码，降低用户的学习成本。

2. ‌完善社区支持‌：

   • 鼓励Anyline团队建立更完善的社区支持体系，如论坛、问答平台等，方便用户交流经验和解决问题。

3. ‌结合项目需求选择工具‌：

   • 在未来的项目中，应根据具体需求选择合适的工具。对于需要快速开发、低代码特性的项目，Anyline是一个不错的选择；而对于需要高度定制化、复杂查询的项目，MyBatis等成熟框架可能更为合适。

4. ‌持续学习与评估‌：

   • 作为开发者，应持续学习新技术和工具，评估其在项目中的适用性和优势。同时，保持开放的心态，勇于尝试新的解决方案，以不断提升自己的技术能力和项目交付质量。

因为使用时间有限，不是非常了解，具体细节就不评论了，还是引用一段官方说明吧：

动态、运行时

即运行时才能最终确定 动态的数据源、数据结构、展现形式
如我们需要开发一个数据中台或者一个数据清洗插件，编码阶段我们还不知道数据来源、什么类型的数据库甚至不是数据库、会有什么数据结构对应什么样的实体类，
如果需要前端展示的话，更不会知道不同的终端需要什么各种五花八门的数据组合
那只能定义一个高度抽象的实体了，想来想去也只有Collection可以胜任了。

简单快速的操作数据库

最常见的操作：根据条件分页查询一个表的几列
这一动就要倾巢出动一整套的service/dao/vo dto 各种O/mapper，生成个查询条件各种封装、为了拼接个SQL又是各种if else forearch
如果查询条件是由前端的最终用户动态提供的，那Java里if完了还不算完，xml中if也少不了
一旦分了页，又要搞出另一套数据结构，另一组接口，另一组参数(当然这种拙劣的设计只是极个别，不能代表ORM)

简单快速的操作结果集

数据库负责的是存储，其结构肯定是与业务需要不一样的。所以结果集需要处理。当我们需要用Map处理数据或数学计算时，
如最常见的数据格式化、筛选、分组、平均值、合计、方差等聚合计算
再如空值的处理包括,"",null,"null","\n","\r","\t"," "全角、半角等各种乱七八糟的情况
这时就会发现Map太抽象了，除了get/set/forearch好像也没别的可施展了。
要处理的细节太多了，if都不够用了。

动态数据源

再比如多数据源的情况下，要切换个数据源又是IOC又是AOP一堆设计模式全出场。经常是在方法配置个拦截器。
在同一个方法里还能切换个数据源了？
数据中台里有可能有几百几千个数据源，还得配上几千个方法？
数据源是用户动态提交的呢怎么拦截呢？
这不是DB Util的本职工作么，还要借助其他？
哪个项目少了AOP依赖还切换不了数据源了？

重复工作

如果只是写个helloworld，以上都不是问题，没什么解决不了的。但实际工作中是需要考虑工作量和开发速度的。
比如一个订单可能有几十上百列的数据，每个分析师需要根据不同的列查询。有那么几十列上同时需要<>=!=IN FIND_IN_SET多种查询方式算正常吧
不能让开发人员挨个写一遍吧，写一遍是没问题，但修改起来可就不是一遍两遍的事了
所以需要提供一个字典让用户自己去配置，低代码开发平台、自定义报表、动态查询条件应该经常有这个需求。
当用户提交上来一个列名、一个运算算、一组值，怎么执行SQL呢，不能在代码中各种判断吧，如果=怎么合成SQL，如果IN怎么合成SQL

多方言

DML方面hibernate还可以处理，DDL呢？国产库呢？

误解

当然我们并不是要抛弃Entity或ORM，相反的 AnyLine源码中也使用了多达几十个Entity
在一些 可预知的 固定的 场景下，Entity的优势还是不可替代的
程序员应该有分辨场景的能力
AnyLine希望程序员手中多一个数据库操作的利器，而不是被各种模式各种hello world限制