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

最近参与了一个项目是给简道云提供后台支持的 用户自己配置数据源生成报表，汇集金蝶用友等系统的进销存财务之类的数据，有点数据中台和低代码的意思。
之前一直都是用mybatis不明白为什么要换个不熟悉的小众工具，
想建议换成mybatis但是没敢说，因为mybatis大家都知道，既然没用肯定是有原因的。
还是研究一下再说下结论吧，
项目进行过程中我才慢慢发现，幸好我没提建议，要不然显得我肤浅了。
如果用了mybatis,光一个查询条件就够我加不完的班了,
处理结果集数据更是个灾难，因为以前用的那些个实体类，现在都不知道怎么创建了。
而且计算个数据真是纯手工打造了。以前都是查出来个实体对象返回给前端还没觉得有什么，现在真要计算数据了才发一实体类根本就不适合处理计算数据。
但是有个非常非常非常糟糕的事情是，anyline的文档很不好用，找文档都不知道怎么找，而且因为版本更新太快，许多文档都是过时的(包括官网文档)。
遇到问题问领导怎么处理，你猜他怎么回复，让我自己猜。这真让我怀疑我是不是真的进了个软件公司。
值得庆幸的是大部分竟然真能猜中了。可见这个anyline的设计还真是按程序员的思路设计的，
这不得不引用一句官方用语：Anyline的一切也源于近一线人员。每个思路、每个类、方法、参数都来自于大家 车到山前那一刻的灵感和期望。
还真是所想即所得。当然这不能掩盖文档的缺陷。总不能什么都靠猜吧，猜错了算谁的。
 

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

动态、运行时

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