AnyLine的核心是一个基于spring-jdbc生态的(No-ORM)数据库操作工具。

其重点是:

1、以最简单、快速、动态的方式操作数据库

2、针对结果集的 数据二次处理能力

简单来说主要作了两方面的工作：

1、在运行时根据需求动态生成SQL(包括DDL和DML),特别是针对查询条件的封装

查询条件不再需要各种空判断、遍历、类型转换,机械繁琐的工作交给机器

这里说的动态是指:

不需要针对固定的表结构或具体的Entity,分别提供不同的Service/Dao/Mapper

一个默认的Service可以操作一切数据

2、为结果集定义了统一的数据结构,主要是DataSet结构类似于List

不要以为DataSet结构比实体类功能类弱

他将提供比实体类更全面、更强大的数据处理能力

为前端或第三方应用提供数据时 不再需要各种遍历、判断、计算、格式转换

一切与业务无关的数学运算,DataSet尽量作到 一键 ... 一键 ...

同时摒弃了各种繁琐呆板的Service/Dao/Entity/*O/Mapper 没有mybatis 没有各种配置 各种O

没有需要自动生成的代码,没有模板文件(自动生成的都是程序员的负担)

适用场景

Anyline一的切都是面向动态、面向运行时环境

适合于抽象设计阶段(实体概念还不明确或者设计工作不局限于某个特别的实体)

常用于需要大量复杂动态的查询，以及查询的结果集需要经过深度处理的场景 如:

可视化数据源

低代码后台

物联网数据处理

数据清洗、数据批量处理

报表输出，特别是用户自定义报表

运行时自定义表单/查询条件/数据结构

网络爬虫数据解析

还有一种很实现的场景是 许多项目到了交付的那一天 实体也没有设计完成

什么情况下说明你的应该考虑换工具了

1、非常简单的增删改查,Entity中大部分只用到了get/set方法,很少需要计算

这一般都是些hello world 或 练习作业

这样的直接利用默认的service查出数据返回给前端就可以收工了

不要再生成一堆重复的模板，简单改个属性也要层层修改，从头改个遍。

2、代码中出现了大量的List,Map结构 或者 针对查询结果集需要大量的二次计算

这种情况应该非常多见

随着系统的增强完善和高度的抽象,同一份数据源将为各种不同的业务场景提供数据支持

每个场景需要的数据结构各不雷同

这时经常是为每类场景订制视图或SQL

但数据支持部门不可能针对每种场景每个视图、每个SQL 生成不同的Entity

更也不可能生成一个大而全的Entity以应万变

3、与第三方系统交换数据时

只在自己内部系统的小圈子里时,List/Entity还勉强可以

遇到各种第三方系统呢，根本不知道会出现什么实体什么结果

难道还要像EJB那样相互给对方生成一堆Bean么?

无论是Map还是Entity计算能力都非常有限,通常需要开发人员各种遍历、计算、格式化

而这种大量的机械的计算不应该占用开发人员太多的时间

Anyline提供的默认数据结构DataSet/DataRow已经实现了常用的数据二次处理功能,如:

排序、维度转换、截取、去重、方差、偏差、交集合集差集、分组、忽略大小写对比、行列转换、类SQL过滤筛选(like,eq,in,less,between...)、JSON、XML格式转换等

不适用场景

对已经非常明确的实体执行增删改查操作

不要跨过设计人员或者架构师/技术经理等直接拿给业务开发人员用