源码属性
授权 | 开源 |
大小 | 1.97MB |
语言 | Java |
源码简介
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格式转换等
不适用场景
对已经非常明确的实体执行增删改查操作
不要跨过设计人员或者架构师/技术经理等直接拿给业务开发人员用
本文永久链接地址:https://www.ymkuzhan.com/66364.html