简介 AnyLine

简介

重要提醒 [2023-08-12]

spring3.x需要jdk17,tomcat10,maven3.8.3支持参考【jdk8>jdk17】【示例源码】
(1)传统业务系统与(2)低代码、中台、自定义查询等动态场景区别比较大，
特别是在构造查询条件时，完全是不同的思路
(1)一般调用controller中的condition()来构造查询条件，简单方便，不需要繁琐的判断遍历
如 service.querys("CRM_USER", condition("ID:id","TYPE:[type]", "CODE:%code%"))，格式参考condition或约定格式
(2)构造查询条件时比较复杂不是k:v格式能胜任的，请务必看明白ConfigStore中的几组方法
另外需要生成DDL/DML但不需要执行，参考【JDBCAdapter】

下载的源码在执行前，首先要配置好maven环境,请参考【maven配置】
关于多数据源，请先看阅读【三种方式注册数据源】【三种方式切换数据源】【多数据源事务控制】
几个容易造成混淆与疑惑的操作【rename】【几个实体类属性的数据类型】【condition()参数】【metadata缓存】【删除列】

有问题请不要自行百度，因为百度收录的内容(包括本站)有可能过期或版本不一致，有问题请联系【技术支持】中的群

尽量不要自己扩展方言，因为Adapter接口现在还在更新中，更新后扩展的方法签名需要修改；所以如果有需要请联系管理员，加几个方法是很快的事。


QQ群

微信群

AnyLine的核心是一个基于spring生态的D-ORM(Dynamic Object Relation Mapping)其重点是:

以最简单、快速方式操作数据库与结果集
兼容各种数据库，统一生成或执行DML/DDL，读写表结构、索引等元数据
一切基于动态、基于运行时(包括数据源、数据结构等)

常用于动态结构的场景中，作为SQL解析引擎或适配器出现 ,
如:数据中台、可视化、低代码、SAAS、自定义表单、异构数据库迁移同步、物联网车联网数据处理、数据清洗、运行时自定义报表/查询条件/数据结构、爬虫数据解析等。参考【适用场景】
主要用来处理：

动态SQL/查询条件
动态实体或无实体结果集相关的数学计算
DDL/DML方言

与ORM最明显的区别是：

摒弃了各种繁琐呆板的实体类以及相关的配置文件
让数据库操作更简单，不要一动就是一整套的service/dao/mapping/VOPODTO有用没用的各种O，生成个简单的SQL也各种判断遍历。
强化了结果集的对象概念
面向对象的对象不是只有get/set/注解这么弱
需要把数据及对数据的操作封装在一起，作为一个相互依存的整体，并实现高度的抽象
要关注元数据，不要关注姓名、年龄等具体属性
强化针对结果集的数据二次处理能力
如结果集的聚合、过滤、行列转换、格式化及各种数学计算尽量作到一键...一键...
而不要像ORM提供的entity,map,list除了提供个get/set/foreach，稍微有点用的又要麻烦程序员各种判断各种遍历

如何实现

数据操作的两个阶段，1.针对数据库中数据 2.针对数据库查询的结果集(内存中的数据)

提供一个通用的AnylineService实现对数据库的一切操作
提供一对DataSet/DataRow实现对内存数据的一切数学计算
DataSet/DataRow不是对List/Map的简单封装他将是提高我们开发速度的重要工具，各种想到想不到的数学计算，只要不是与业务相关的都应该能实现

为什么需要有AnyLine
AnyLine的用户按来源大概分两类，一类是技术选型过程中选到了AnyLine,这类用户既然有造型能力，那他需要什么以及AnyLine能提供什么自己是非常清晰的。对于这类用户也不需要解释什么了。
主要是第二类用户，是参与的项目中已经有了AnyLine，属于被动接收。
对于这类用户首先会有个疑问：已经了有spring-data,hibernate,mybatis 为什么还多此一AnyLine

如果只是Hello World似的增删改查,那确实不需要，但实际工作中发现太难了、工作量太大了。（补充：工作不是指找工作不是求职面试,找工作anyline是个减分项）
还是从动态、简单、结果集说起

动态、运行时
即运行时才能最终确定动态的数据源、数据结构、展现形式
如我们需要开发一个数据中台或者一个数据清洗插件，编码阶段我们还不知道数据来源、什么类型的数据库甚至不是数据库、会有什么数据结构对应什么样的实体类，
如果需要前端展示的话，更不会知道不同的终端需要什么各种五花八门的数据组合
那只能定义一个高度抽象的实体了，想来想去也只有Collection<Map>可以胜任了。
简单快速的操作数据库
最常见的操作：根据条件分页查询一个表的几列
这一动就要倾巢出动一整套的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呢？国产库呢？小众库呢？
比如作一个异构数据库迁移工具，还能要求用户熟悉每种数据库的语法？是不是应该让用户提供几个参数自动生成就可以了。
比如提供*表示同步所有表，*-T1,T2表示同步除了T1,T2之外的所有表，不能让用户为每个表针对不同的库写不同的SQL吧。

当然这种问题很难有定论，只能在实际应用过程中根据情况取舍。以参考【适用场景】和【实战对比】中的示例

选型之前，当然要搞明白优势劣势，参考【优势劣势】

误解

当然我们并不是要抛弃Entity或ORM，相反的 AnyLine源码中也使用了多达几十个Entity(如几何图形等)
在一些可预知的固定的场景下，Entity的优势还是不可替代的
程序员应该有分辨场景的能力

如何使用

数据操作不要再从生成xml/dao/service以及各种配置各种O开始
默认的service已经提供了大部分的数据库操作功能。
操作过程大致如下:

DataSet set = service.querys("HR_USER(ID,NM)",   condition(true,"anyline根据约定自动生成的=,in,like等查询条件"));

这里的查询条件不再需要各种配置,各种if else foreach标签
Anyline会自动生成,生成规则可以参考这里的【约定规则】
分页也不需要另外的插件，更不需要繁琐的计算和配置，指定true或false即可

如何集成

只需要一个依赖、一个注解即可实现与springboot,netty等框架项目完美整合，参考【入门系列】
大概的方式就是在需要操作数据库的地方注入AnylineService
接下来service就可以完成大部分的数据库操作了。常用示例可以参考【示例代码】

关于数据库的适配

直接看示例(代码都是一样的、可以用来测试一下自己的数据库是否被支持)

https://gitee.com/anyline/anyline-simple/tree/master/anyline-simple-data-jdbc-dialect

MariaDB

Apache Hive IBM DB2

达梦

人大金仓

瀚高

南大通用

神舟通用

TiDB

citus

没有示例的看这个目录下有没有【anyline-data-jdbc-dialect】还没有的请联系【技术支持】中的管理员