摒弃了各种繁琐呆板的Service/Dao/Entity/O/Mapper 没有mybatis 没有各种配置 各种O
适用场景Anyline一的切都是面向动态、面向运行时环境适宜于抽象设计阶段(实体观点还不明确或者设计不限于某个特殊的实体)常用于须要大量繁芜动态的查询，以及查询的结果集须要经由深度处理的场景 如:
可视化数据源低代码后台物联网数据处理数据洗濯、数据批量处理报表输出，特殊是自定义报表运行时自定义表单/查询条件/数据构造还有一种很实现的场景是 许多项目到了交付的那一天 实体也没有设计完成不适用场景对已经非常明确的实体实行增编削查操作不要跨过设计职员直接拿给业务开拓职员用
数据操作不要再从天生xml/dao/service以及各种配置各种O开始默认的service已经供应了大部分的数据库操作功能。操作过程大致如下:
DataSet set = service.querys("HR_USER(ID,NM)", condition(true,"anyline根据约定自动天生的=,in,like等查询条件"));
这里的查询条件不再须要各种配置,各种if else foreach标签Anyline会自动天生,生成规则可以参考这里的【约定规则】分页也不须要其余的插件，更不须要繁琐的打算和配置，指定true或false即可繁琐机器的事情不要摧残浪费蹂躏程序员的韶光
返回的DataSet上附加了常用的数据二次处理功能如:排序、维度转换、截取、去重、方差、偏差、交凑集集差集、分组、行列转换、类SQL过滤筛选(like,eq,in,less,between...)、JSON、XML格式转换等
如何集成只须要一个依赖、一个表明即可实现与springboot,netty等框架项目完美整合直接看代码【anyline-simple-hello】生产环境可以参考这几个pom【anyboot-start】 没有web环境,如定时任务,爬虫等【anyboot-start-mvc】 基于spring-mvc【anyboot-start-mvc-mysql】 基于spring-mvc MySQL数据库【anyboot-start-mvc-jsp-mysql】 基于spring-mvc MySQL数据库 支持JSP以下可以略过
根据数据库类型添加依赖,如
<dependency> <groupId>org.anyline</groupId> <artifactId>anyline-jdbc-mysql(oracle|clickhouse...)</artifactId> <version>8.5.3-20220630</version></dependency>
在须要操作数据库的地方注入AnylineService
@Qualifier("anyline.service")protected AnylineService service;
接下来service就可以完成大部分的数据库操作了。常用示例可以参考【示例代码】
兼容如果实现放不下那些已存在的各种XOOODataSet与Entity之间可以相互转换或者这样:
EntitySet<User> = service.querys(User.class, condition(true,"anyline根据约定自动天生的查询条件")); //true：表示须要分页//为什么不用返回的是一个EntitySet而不是List?//由于分页情形下,EntitySet中包含了分页数据,而List弗成。//无论是否分页都返回相同的数据构造，而不须要根据是否分页实现两个接口返回不同的数据构造//也可以这样(如果真要这样就不要用anyline了,还是用MyBatis,Hibernate之类吧)public class UserService extends AnylinseService<User> userService.querys(condition(true,"anyline根据约定自动天生的查询条件")); 实战比拟
在空想的HelloWord环境下，任何办法都可以快速实现目标，更能表示利害的是繁芜多变的实战环境。
首先要承认银弹是没有的，以是先说 劣势在增、删、改、查4个过程中，增的环境劣势比较明显操作查询结果时，不能像Entity一样有IDE的提示和自动补齐，减少了IDE的帮忙确实让许多人寸步难行，大部分人也是在这里被劝退的。在插入数据时，不能像像Entity一样:userService.save(user)，而是须要指定表名:service.save(HR_USER, row);以上问题如果平衡的AnyLine返回的结果集与Entity之间随时可以相互转换,也可以在查询时直接返回Entity有思想的程序员会想为何要造个轮子 可靠吗，以是再说 疑问AnylineLine并非新造了一个轮子，只是大略的把业务参数传给了底层的spring-jdbc接下来的操作（如事务掌握、连接池等）完备交给了spring-jdbc(没有能力作好的事我们不作)如果非要说是一个新轮子，那只能说原来的轮子太难用，太花费程序员体力了。正事还没开始就师长西席成一堆的mapper,OOO，各种铺垫铺垫完了要操作数据实现业务了，依然啰嗦，各种 劳力 不劳心 的遍历及加减乘除以是重点说 上风1.关于查询条件这是开拓职员最繁重的体力劳动之一吸收参数、验证、格式化、层层封装通报到mapper.xml，再各种判断、遍历就为天生一条SQL下面的这些标签许多人可能觉得习以为常了
<if test="code != null and code != '' "> AND CODE = #{code} </if> <if test="name != null and name != '' "> AND NAME like concat('%',#{name},'%')</if><if test="types != null and types.size > 0 "> AND TYPE IN <foreach collection="types" item="type" open="(" close=")" separator=","> #{type} </foreach></if>
但这并不正常，这期间还有什么是必须程序员参的，程序员不参与就自动不了，就约定不了的吗？ 换一种办法处理： 不要mapper.xml了，也更不要定位SQL的ID的 直接在java中这样处理，其他的交给工具 condition("CODE:code","NAME:name%", "TYPE:[type]")
这该当不须要注释了，更多的约定可以参考这里的【约定规则】
2.结果集的二次操作这是开拓职员最繁重的劳动之二从数据库中查询出数据后，根据业务需求还须要对结果集作各种操作，最大略的如加减乘除、交集差集、筛选过滤等这些常见的操作DataSet中都已经供应默认实现了，如ngl表达式、聚合函数、类SQL筛选过滤、维度转换等。
3.关于面向动态与运行时环境这里说的动态是指出动态数据源、动态数据构造、动态结果集运行时环境是指在系统运行阶段才能确定以上内容，而不是在需求、设计、编码阶段
动态数据源：一样平常是在系统运行时天生范例场景如数据中台，用户通过管理端提交第三方数据库的地址帐号，中台汇聚多个数据源的数据这种情形下显示不是在配置文件中添加多个数据源可以办理的而是须要在吸收到用户提交数据后，天生动态的数据源天生的动态数据源最好交给Spring等容器管理以充分利用其生态内的连接池,事务管理,切面等现有工具在切换数据源时也不能通过切面来实现而是根据组织或租户身份等高下文环境来切换
动态数据构造:一样平常由非专业开拓职员乃至是终极用户来设计表构造根据用户设置或不同场景返回不同构造的结果集查询条件也由用户动态指定结果集与查询条件的选择范围也不能在编码阶段设置限定范例场景如物联网平台仪器设备参数、低代码平台、报表工具
常用的数据构造有两种1).DataRow类似于一个Map2).DataSet是DataRow的凑集，并内含了分页信息
以了局景中将逐步表示出相对付List,Entity的上风
1). 最常见的如更新或查询部分列DataRow row = service.query("HR_USER(ID,CODE)")service.update(row,"CODE")
2).可视化数据源、报表输出、数据洗濯这些场景下都须要的数据构造都是灵巧多变的常常是针对不同的业务从多个表中合身分歧的构造集乃至是运行时根据用户输入动态结合的构造集输出结果集后又须要大量的比拟及聚合操作这种情形下显示不可能为每个结果集天生一个对应Entity，只能是动态的Map构造在对构造集的二次操作上,DataRow/DataSet可以在抽象设计阶段就完成，而Entity却很难
3).低代码后台、元数据管理作为一个低代码的后台，首先须要详细灵巧可定制的表构造(常日会是一个半静半动的构造)我们将不再操作详细的业务工具与属性。对大部分业务的操作都只能通过抽象的元数据进行。举例来说一个大略的求和过程，原来在对静态构造时常用的的遍历、Lamda、反射都尴尬重任了。我们能吸收到的信息常日是这样的:类型(学生)、属性(年事)、条件(年级=1)、聚合公式(均匀值)Anyline的实现过程类似这样DataSet set = service.querys(学生,年级=1);int 均匀年事 = set.agg(均匀值,年事);
4).运行时自定义表单、查询条件许多情形下我们的根本版本产品，很难知足用户100%的需求，而这些新需求又大部分是一些大略的表单、查询条件如果是让程序员去开拓一个表单，添加几个查询条件，那确实很大略但用户不是程序员，我们也不可能为每个用户供应全面全天候的技能支持考虑到本钱与用户体验的问题常日会给用户供应一个自定义表单与查询条件的功能自定义并不难，难的是对自定义表单的存储、查询、关联，以及对自定义查询条件的支持与上一条说的元数据管理一样，我们在代码实现环节还是不知道会有什么工具什么属性当然也更不会有对应的service, dao, mapper, VO/DTO/BO/DO/PO/POJOAnyline的动态查询类似这样实现service.query(类型(属性凑集),condition().add('比拟办法','属性','值');
5).物联网环境(特殊是像Cassandra、ClickHouse等列式数据库 InfluxDB、TimescaleDB等时序数据库)与低代码平台类似都须要一种动态的构造，并且为了数据读取的高效，数据在水平方向上变的更分散。这与终极用户须要显示的格式完备不一样，直接通过数据库查询出来的原始数据常日是类似这样
韶光戳
KEY
VALUE
1657330073131
LAT
39.917055
1657330073131
LNG
116.392191
1657330073132
LAT
39.917055
1657330073132
LNG
116.392191
1657330073133
LAT
39.917055
1657330073134
LNG
116.392191
而终极展示的界面可能是这样：
韶光戳
LNG
LAT
1657330073131
116.392191
39.917055
1657330073131
116.392191
39.917055
日期(向下合并)
韶光点1(向右合并)
韶光点2(向右合并)
韶光点...N
LNG
LAT
LNG
LAT
LNG
LAT
01-01
116.392191
39.917055
116.392191
39.917055
116.392191
39.917055
01-02
116.392191
39.917055
116.392191
39.917055
116.392191
39.917055
当然实战中会比这更繁芜，历经实战的程序员一定体验过什么是千变万化、什么是刁钻苛刻数据库中将不再有逐一对应的hello表格，java中也没有对应的Entity可以想像的出来基于一个静态构造或者原始的Map,List构造须要程序员卖力多少体力要在这个根本上实现让用户自定义报表，那可能比把用户培养成一个程序员还要困难
而一个有思想的程序员该当会把以上问题抽象成大略的行列转换的问题并在项目之前乃至没有项目的时候就已经办理之。各种维度的转换可以参考DataSet.pivot()的几个重载 或示例代码 anyline-simple-result
6).关于分页查询的数据存储构造通过默认的办法查询无论是否分页 都可以通过DataSet构造吸收数据不同的是分页后DataSet.PageNavi中会嵌入详细的分页信息通过User.class查询数据时如果没有分页 可以通过List<User>>构造吸收数据如果有分页了 那须要通过Page<List<User>>构造吸收数据大略查询个部门列表，还要根据分不分页写两个接口吗7).数据加密对付须要加密的数据常常会碰着数字类型的ID而加密后的数据类型常日是String类型，导致原工具无法存储
就先更到这里了，有须要数据库操尴尬刁难象的朋友关注+转发+评论之后私信我【数据库】即可。
