The core of AnyLine is a spring jdbc based (No ORM) database operation tool.
The key points are:
1. Operate the database in the simplest, fastest, and most dynamic way
2. Data secondary processing capability for result set
In brief, two aspects of work have been done:
1. Dynamically generate SQL (including DDL and DML) according to requirements at runtime, especially for the encapsulation of query conditions
The query conditions no longer require various null judgments, traversals, and type conversions, and the tedious mechanical work is handed over to the machine
The dynamic here refers to:
It is not necessary to provide different Services/Dao/Mappers for fixed table structures or specific Entities
A default service can operate all data
2. Unified data structure is defined for the result set, mainly DataSet Structure is similar to List
Don't assume that DataSet Structure is weaker than entity class function class
It will provide more comprehensive and powerful data processing capabilities than entity classes
When providing data for front-end or third-party applications, it no longer requires various traversal, judgment, calculation and format conversion
All non business related mathematical operations, DataSet Try to press one key One click
At the same time, all kinds of tedious and rigid services/Dao/Entity/* O/Mapper have no mybatis, no various configurations and various O
No code needs to be generated automatically, no template file (automatic generation is the burden of programmers)
Applicable scenarios
Anyline is all dynamic and runtime oriented
Suitable for abstract design stage (entity concept is not clear or design work is not limited to a particular entity)
It is often used in scenarios where a large number of complex and dynamic queries are required and the query result set needs to be deeply processed, such as:
Visual data source
Low code background
Internet of Things data processing
Data cleaning and batch processing
Report output, especially user-defined reports
Run time custom form/query condition/data structure
Analysis of web crawler data
Another very practical scenario is that many projects have not been designed on the day of delivery
When does it mean you should consider changing tools
1. It is very simple to add, delete, modify and check. Most of Entity only uses get/set methods, and few calculations are needed
This is usually some hello world or exercise homework
In this way, we can directly use the default service to find out the data and return it to the front end
Do not regenerate into a pile of duplicate templates. Simply change a property layer by layer, and change it again from the beginning.
2. A large number of List and Map structures appear in the code, or a large number of secondary calculations are required for query result sets
This situation should be very common
With the enhancement, perfection and high abstraction of the system, the same data source will provide data support for different business scenarios
Each scenario requires different data structures
At this time, it is often necessary to customize views or SQL for each type of scenario
However, the data support department cannot generate different Entities for each scenario, each view, and each SQL
It is also impossible to generate a large and comprehensive Entity to cope with changes
3. When exchanging data with a third-party system
Only in the small circle of its own internal system, List/Entity can barely
When encountering various third-party systems, I don't know what entities and results will occur
Do you want to generate a bunch of beans for each other like EJB?
Both Map and Entity have very limited computing power, which usually requires developers to traverse, calculate and format
Such a large number of mechanical calculations should not occupy too much time of developers
The default data structure DataSet/DataRow provided by Anyline has realized common data secondary processing functions, such as:
Sort, dimension conversion, interception, de duplication, variance, deviation, intersection, aggregation, difference, grouping, ignore case comparison, row column conversion, SQL like filtering (like, eq, in, less, between...), JSON, XML format conversion, etc
Not applicable scenario
Add, delete, modify and query entities that have been very clear
Do not pass over the designer or architect/technical manager to the business developer directly
