# anyline **Repository Path**: LevelCoder/anyline ## Basic Information - **Project Name**: anyline - **Description**: 一个天然的低代码、动态表单、动态数据源底层工具，运行时动态注册切换数据源，自动生成SQL(DDL/DML/DQL)，读写元数据，对比数据库结构差异。No-Entity，适配100+关系/非关系数据库。常用于动态场景的底层支持,如:数据中台、低代码、可视化、工作流、自定义表单、异构数据库迁移同步、物联网车联网数据处理、数据清洗、运行时自定义报表/查询条件/数据结构、爬虫数据解析等 - **Primary Language**: Java - **License**: Apache-2.0 - **Default Branch**: master - **Homepage**: http://doc.anyline.org/ - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 844 - **Created**: 2024-11-19 - **Last Updated**: 2024-11-19 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README [![EN doc](https://img.shields.io/badge/document-English-blue.svg)](README.md) [![CN doc](https://img.shields.io/badge/文档-中文版-blue.svg)](README_zh_CN.md)


QQ群(86020680)	微信群	过期或满员联系管理员
有问题请联系以上群(无论BUG、疑问、需求、源码、竞品)

***快速测试请参考[【anyline-simple-clear】](https://gitee.com/anyline/anyline-simple-clear)*** ***详细语法请参考[【anyline-simple】](https://gitee.com/anyline/anyline-simple)*** 关于多数据源，请先阅读 [【六种方式注册数据源】](http://doc.anyline.org/aa/a9_3451) [【三种方式切换数据源】](http://doc.anyline.org/aa/64_3449) [【多数据源事务控制】](http://doc.anyline.org/ss/23_1189) 低代码平台、数据中台等场景需要生成SQL/操作元数据参考 [【JDBCAdapter】](http://doc.anyline.org/ss/01_1193) [【返回SQL方言、导出SQL】](http://doc.anyline.org/aa/70_3793) [【表结构差异对比及生成DDL】](http://doc.anyline.org/aa/a2_3936) [【ConfigStore与JSON互换】](http://doc.anyline.org/aa/73_13975) [【service.metadata】](http://doc.anyline.org/ss/22_1174) [【SQL.metadata】](http://doc.anyline.org/aa/c1_3847) ## 简介 AnyLine的核心是一个面向运行时的元数据动态关系映射主要用于 - 动态注册切换数据源 - 读写元数据 - 对比数据库结构差异 - 生成动态SQL,组合动态查询条件 - 复杂的结果集操作一个天然的低代码、动态表单、动态数据源底层工具适配各种关系型与非关系型数据库(及各种国产小众数据库) 常用于动态结构场景的底层支持，作为SQL解析引擎或适配器出现如:数据中台、可视化、低代码、SAAS、自定义表单、异构数据库迁移同步、物联网车联网数据处理、条件/数据结构、爬虫数据解析等。参考【[适用场景](http://doc.anyline.org/ss/ed_14)】 ##### 数据源注册及切换注意这里的数据源并不是主从关系，而是多个完全不相关的数据源。 ```java DataSource ds_sso = new DruidDataSource(); ds_sso.setUrl("jdbc:mysql://localhost:3306/sso"); ds_sso.setDriverClassName("com.mysql.cj.jdbc.Driver"); ... DataSourceHolder.reg("ds_sso", ds_sso); 或 DataSourceHolder.reg("ds_sso", pool, driver, url, user, password); DataSourceHolder.reg("ds_sso", Map params); //对应连接池的属性k-v //查询ds_sso数据源的SSO_USER表 DataSet set = ServiceProxy.service("ds_sso").querys("SSO_USER"); ``` 来自静态配置文件数据源(如果是spring环境可以按spring格式) ```properties #默认数据源 anyline.datasource.type=com.zaxxer.hikari.HikariDataSource anyline.datasource.driver-class-name=com.mysql.cj.jdbc.Driver anyline.datasource.url=jdbc:mysql://localhost:33306/simple anyline.datasource.user-name=root ...更多参数 #其他数据源 anyline.datasource-list=crm,erp,sso,mg anyline.datasource.crm.driver-class-name=com.mysql.cj.jdbc.Driver anyline.datasource.crm.url=jdbc:mysql://localhost:33306/simple_crm anyline.datasource.crm.username=root anyline.datasource.erp.driver-class-name=com.mysql.cj.jdbc.Driver anyline.datasource.erp.url=jdbc:mysql://localhost:33306/simple_erp anyline.datasource.erp.username=root ``` DML ```java 如果是web环境可以 service.querys("SSO_USER", condition(true, "NAME:%name%", "TYPE:[type]", "[CODES]:code")); //true表示需要分页,没有传参籹值的条件默认忽略 //生成SQL: SELECT * FROM SSO_USER WHERE 1=1 AND NAME LIKE '%?%' AND TYPE IN(?,?,?) AND FIND_IN_SET(?, CODES) LIMIT 5,10 //根据具体数据库类型 //用户自定义查询条件,低代码等场景一般需要更复杂的查询条件 ConfigStore configs; service.query("SSO_USER", configs); ConfigStore提供了所有的SQL操作 //多表、批量提交、自定义SQL以及解析XML定义的SQL参数示例代码和说明 ``` 读写元数据 ```java @Autowired("anyline.service") AnylineService service; //查询默认数据源的SSO_USER表结构 Table table = serivce.metadata().table("SSO_USER"); LinkedHashMap columns = table.getColumns(); //表中的列 LinkedHashMap constraints = table.getConstraints(); //表中上约束 List ddls = table.getDdls(); //表的创建SQL //删除表重新创建 service.ddl().drop(table); table = new Table("SSO_USER"); //这里的数据类型随便写，不用管是int8还是bigint,执行时会转换成正确的类型 table.addColumn("ID", "BIGINT").autoIncrement(true).setPrimary(true).setComment("主键"); table.addColumn("CODE", "VARCHAR(20)").setComment("编号"); table.addColumn("NAME", "VARCHAR(20)").setComment("姓名"); table.addColumn("AGE", "INT").setComment("年龄"); service.ddl().create(table); 或者service.ddl().save(table); 执行时会区分出来哪些是列需要add哪些列需要alter ``` 事务 ```java //因为方法可以有随时切换多次数据源,所以注解已经捕捉不到当前数据源了 //更多事务参数通过TransactionDefine参数 TransactionState state = TransactionProxy.start("ds_sso"); //操作数据 TransactionProxy.commit(state); TransactionProxy.rollback(state); ``` ### 已经有ORM了为什么还要有AnyLine, 与ORM有什么区别 - ***面向场景不同*** anyline主要面向动态场景，就是运行时随时可变的场景。如我们常用的动态数据源，不是在部署时可以固定在配置文件中，而是可能在不确定的时间，由不确定的用户提供的不确定数据源。表结构等元数据也可能随着着用户或数据源的不同而随时变化。 - ***针对产品不同*** anyline一般不会直接用来开发一个面向终端用户的产品(如ERP、CRM等)，而是要开发一个中间产品(如低代码平台)，让用户通过中间产品来生成一个最终产品。再比如用anyline开发一个自定义查询分析工具，让用户通过这个工具根据业务需求生成动态报表。 anyline不是要提供一个可二次开发的半成品船，而是可以用来造船的动态船坞。 - ***操作对象不同*** anyline主要操作元数据，因为在项目开发之初，可能就没有一个如ERP/CRM之类的明确的产品，当然也就没有订单、客户之类的具体对象及属性，所以也没什么具体数据可操作。 - ***面向用户(开发设计人员)不同*** anyline要面向的不是开船的人，而是造船的人，而不是使用工具的人，而是设计工具的人。 anyline的大部分代码与灵感也是来自这部分用户的日常实践。 - ***所以对用户(开发设计人员)要求不同*** 一个ORM用户用了许多年的连接池，他可以只知道配置哪几个默认参数，也能正常开展工作。但anyline的用户不行，他要求这个团队中至少有一个人要明白其所以然。 ### 实际操作中与ORM最明显的区别是 - ***摒弃了各种繁琐呆板的实体类以及相关的配置文件*** 让数据库操作更简单，不要一动就是一整套的service/dao/mapping/VOPODTO有用没用的各种O，生成个简单的SQL也各种判断遍历。 - ***强强化了结果集的对象概念*** 面向对象的对象不是只有get/set/注解这么弱需要把数据及对数据的操作封装在一起，作为一个相互依存的整体，并实现高度的抽象要关注元数据，不要关注姓名、年龄等具体属性强化针对结果集的数据二次处理能力如结果集的聚合、过滤、行列转换、格式化及各种数学计算尽量作到一键...一键... 而不要像ORM提供的entity, map, list除了提供个get/set/foreach，稍微有点用的又要麻烦程序员各种判断各种遍历参考【[疑问与优劣对比](http://doc.anyline.org/ss/ae_1196)】 ### 与如何实现数据操作的两个阶段，1.针对数据库中数据 2.针对数据库查询的结果集(内存中的数据) - ***提供一个通用的AnylineService实现对数据库的一切操作*** - ***提供一对DataSet/DataRow实现对内存数据的一切数学计算*** DataSet/DataRow不是对List/Map的简单封装他将是提高我们开发速度的重要工具，各种想到想不到的数学计算，只要不是与业务相关的都应该能实现 ## 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依赖还切换不了数据源了？ ### 重复工作如果只是写个hello world，以上都不是问题，没什么解决不了的。但实际工作中是需要考虑工作量和开发速度的。比如一个订单可能有几十上百列的数据，每个分析师需要根据不同的列查询。有那么几十列上同时需要<>=!=IN FIND_IN_SET多种查询方式算正常吧不能让开发人员挨个写一遍吧，写一遍是没问题，但修改起来可就不是一遍两遍的事了所以需要提供一个字典让用户自己去配置，低代码开发平台、自定义报表、动态查询条件应该经常有这个需求。当用户提交上来一个列名、一个运算算、一组值，怎么执行SQL呢，不能在代码中各种判断吧，如果=怎么合成SQL，如果IN怎么合成SQL ### 多方言 DML方面hibernate还可以处理，DDL呢？国产库呢？当然这种问题很难有定论，只能在实际应用过程中根据情况取舍。可以参考【[适用场景](http://doc.anyline.org/ss/ed_14)】和【[实战对比](http://doc.anyline.org/ss/c9_1153)】中的示例选型之前，当然要搞明白优势劣势，参考【[优势劣势](http://doc.anyline.org/aa/24_3712)】 ## 误解当然我们并不是要抛弃Entity或ORM，相反的 AnyLine源码中也使用了多达几十个Entity 在一些 **可预知的固定的** 场景下，Entity的优势还是不可替代的程序员应该有分辨场景的能力 AnyLine希望程序员手中多一个数据库操作的利器，而不是被各种模式各种hello world限制 ## 如何使用数据操作***不要***再从生成xml/dao/service以及各种配置各种O开始默认的service已经提供了大部分的数据库操作功能。操作过程大致如下: ``` DataSet set = service.querys("HR_USER(ID, NM)", condition(true, "anyline根据约定自动生成的=, in, like等查询条件")); ``` 这里的查询条件不再需要各种配置, 各种if else foreach标签 Anyline会自动生成, 生成规则可以参考这里的[【约定规则】](http://doc.anyline.org/s?id=p298pn6e9o1r5gv78acvic1e624c62387f2c45dd13bb112b34176fad5a868fa6a4) 分页也不需要另外的插件，更不需要繁琐的计算和配置，指定true或false即可 ## 如何集成只需要一个依赖、一个注解即可实现与springboot, netty等框架项目完美整合，参考【入门系列】大概的方式就是在需要操作数据库的地方注入AnylineService 接下来service就可以完成大部分的数据库操作了。常用示例可以参考【[示例代码](https://gitee.com/anyline/anyline-simple)】 ## 兼容如果实现放不下那些已存在的各种XOOO DataSet与Entity之间可以相互转换或者这样: ``` EntitySet = service.querys(User.class, condition(true, "anyline根据约定自动生成的查询条件")); //true：表示需要分页 //为什么不用返回的是一个EntitySet而不是List? //因为分页情况下, EntitySet中包含了分页数据, 而List不行。 //无论是否分页都返回相同的数据结构，而不需要根据是否分页实现两个接口返回不同的数据结构 //也可以这样(如果真要这样就不要用anyline了, 还是用MyBatis, Hibernate之类吧) public class UserService extends AnylinseService userService.querys(condition(true, "anyline根据约定自动生成的查询条件")); ``` ## 适用场景 - **低代码后台** 主要用来处理动态属性、动态数据源、运行时自定义查询条件、元数据管理等。比较容易落地的几个场景如财务、库存等ERP模块用户经常需要输出不同格式的报表，根据不同维度查询统计数据前端可以用百度amis前端低代码框架，后端由anyline解析SQL及查询条件，管理元数据。 [【示例】](/anyline/service) - **数据中台** 动态处理各种异构数据源、强大的结果集批量处理能力，不再需要对呆板的实体类各种遍历各种转换。通常需要在运行时频繁的注册、切换、注销数据源 [【示例】](/anyline/anyline-simple) - **可视化数据源** 主要用来处理动态属性，以及适配前端的多维度多结构的数据转换可视化中最主要的工作就是生成图表了，如果是通过map可实体类那又免不了各种判断、遍历、计算如果是有限的几个固定的图表还可以处理，如果是大量的动态图表呢(比如由前端用户提供统计方式与维度) [【参考】](http://doc.anyline.org/a?id=p298pn6e9o1r5gv78vicac1e624c62387f7bb5cdeaeddf6f93f9eb865d5cc60b9b) - **物联网车联网数据处理** 如车载终端、交通信号灯、数字化工厂传感器、环境检测设备数据等这种场景通常会涉及到时序数据库时序库虽然快，但是结构简单，数据需要经过各种组合后给业务系统时序库通常需要在运行时操作大量的DDL [【示例】](/anyline/service) - **数据清洗、数据批量处理** 各种结构的数据、更多的是不符合标准甚至是错误的结构这种场景下需要一个灵活的数据结构来统一处理各种结构的数据再想像一下临时有几个数据需要处理一下(如补齐或替换几个字符) 这个时候先去创建个Entity, XML, Service, Dao吗 [【示例】](/anyline/service) - **报表输出，特别是用户自定义报表** 类似于可视化环境, 样式相对简单一点，但精度要求极高，需要控制到像素、字体等如检验检测报告、资质证书等，当然这需要配合 anyline-office [【office示例】](http://office.anyline.org/v/b6_3797) - **工作流(运行时自定义表单/查询条件/数据结构)** 各个阶段都要自定义，比低代码要求更高的是:操作用户不懂编程 [【示例】](/anyline/service) - **网络爬虫数据解析** 不固定的结构、html解析(当然不是用正则或dom那太费脑子了) [【参考】](http://doc.anyline.org/s?id=p298pn6e9o1r5gv78acvic1e624c62387f51d08504f16eef5d4dd25719cf7844ce) - **异构数据库迁移同步** 动态的数据结构可以灵活的适配多种不同的表, 需不需要反复的get/set 兼容多种数据库的DDL也可以方便的在不同类型的数据库中执行 [【核心代码示例(Mysql到Apache Ignite)】](http://doc.anyline.org/aa/08_3842) [【基础应用项目】](/anyline/anyline-database-sync) [【完整应用代替datax】](/czarea/devops) - **还有一种很实现的场景是许多项目到了交付的那一天实体也没有设计完成** 别说设计了，需求都有可能还没结束就催交付了, Entity哪里找 [【示例】](/anyline/service) ## 关于数据库的适配 [【更多查看】](http://doc.anyline.org/dbs) [【示例源码】](/anyline/anyline-simple/tree/master/anyline-simple-data-jdbc-dialect) MYSQL