A method, device and medium for creating dynamic forms

Abstract

This application discloses a dynamic form construction method, device, and medium, relating to the fields of software engineering and enterprise application development technology. The method includes: receiving a form request containing a view model identifier and request type based on a preset view parsing and execution engine; parsing a predefined view model according to the identifier to obtain its metadata, which defines the target business entity, view data object structure, field set, and filtering conditions; for data query requests, dynamically constructing and executing SQL statements based on the aforementioned metadata, obtaining raw data, performing aggregation and transformation, and generating structured view data that meets the front-end rendering requirements for return; for data submission requests, converting the data submitted from the front-end back into domain model data according to the same view model, and calling the business entity engine service to complete business logic verification and persistent storage, thereby achieving dynamic generation of the form view, decoupling of front-end and back-end logic, and ensuring business consistency.

Description

Technical Field

[0001] This application relates to the fields of software engineering and enterprise application development technology, and in particular to a dynamic form construction method, device and medium. Background Technology

[0002] In enterprise application development, traditional form creation typically employs a tightly coupled front-end and back-end architecture. For each form requirement, separate data interfaces, business logic, and front-end interfaces must be developed, leading to code redundancy and high maintenance costs. The fragmentation of business rules also easily causes inconsistencies between front-end and back-end logic.

[0003] To alleviate the aforementioned problems, the BackendsforFrontends pattern emerged. However, in practice, it often employs static interface aggregation, still requiring the writing of specific adaptation code for various view types such as lists, details, and different terminals. This fails to fundamentally reduce development workload; instead, it makes the middleware bloated and necessitates simultaneous modifications in multiple places when business changes occur, resulting in insufficient system flexibility. The key flaw of existing technologies lies in the lack of dynamism and model-driven capabilities in form view generation, making it impossible to quickly define diverse views through configuration and automatically handle consistent data acquisition, transformation, and persistence.

[0004] Therefore, how to implement a highly decoupled, configurable, and dynamic form construction method to significantly improve development efficiency, view customization capabilities, and system maintainability has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] This application provides a dynamic form construction method, device, and medium to solve the following technical problem: how to implement a highly decoupled, configurable, and driven dynamic form construction method to significantly improve development efficiency, view customization capabilities, and system maintainability.

[0006] In a first aspect, embodiments of this application provide a dynamic form construction method, the method comprising: receiving a form request from a front-end based on a preset view parsing and running engine; wherein the form request includes a view model identifier and a request type; the request type includes data query and data submission; retrieving and parsing a predefined target view model based on the view model identifier to determine the metadata definition corresponding to the target view model; wherein the metadata definition includes: a target business entity identifier, a target view data object structure, a set of fields contained in the target view data object structure, and a filter condition configuration; when the request type is a data query, dynamically constructing a structured query language statement according to the target view data object structure, the set of fields, and the filter condition configuration to obtain the original dataset from the database, and performing aggregation and transformation processing on the original dataset according to the target view model to generate and return target view data that meets the front-end rendering requirements; when the request type is a data submission, converting the received front-end submitted data into domain model data according to the target view model, and calling an independent business entity engine service to perform business logic verification and consistent persistent storage on the domain model data.

[0007] In one embodiment of this application, based on the view model identifier, a predefined target view model is retrieved and parsed to determine the metadata definition corresponding to the target view model. Specifically, this includes: retrieving the corresponding view model configuration document from the view model registry based on the view model identifier, and parsing the view model configuration document to obtain the target business entity identifier; wherein, the target business entity identifier is used to point to an aggregate root composed of business fields; parsing the data object reference relationship defined in the view model configuration document to construct the target view data object structure; wherein, the target view data object structure is used to indicate the hierarchical relationship from the aggregate root main table to the associated data object table; parsing the field selection and display attribute configuration defined for each data object in the target view data object structure in the view model configuration document to form a field set, and parsing the filtering rules defined in the view model configuration document to form a filtering condition configuration.

[0008] In one embodiment of this application, a structured query language statement is dynamically constructed based on the target view data object structure, field set, and filter condition configuration. Specifically, this includes: determining the main data object table to be queried and one or more subordinate data object tables derived through association relationships based on the target view data object structure; selecting a list of target field names from the main data object table and one or more subordinate data object tables based on the field set; combining the filter fields, operators, and passed filter values ​​defined in the filter condition configuration into one or more query condition expressions; and automatically adding join clauses between the main data object table and one or more subordinate data object tables based on database association relationships, and integrating the target field name list with one or more query condition expressions to dynamically construct a complete structured query language statement.

[0009] In one embodiment of this application, the original dataset is aggregated and transformed according to the target view model to generate and return target view data that meets the requirements of front-end rendering. Specifically, this includes: performing field pruning on the original dataset according to the target view data object structure and field set, filtering out redundant field data that is not referenced by the target view model, and obtaining a pruned dataset; performing real-time access control and sensitive information transformation processing on specific rows or columns of data in the pruned dataset according to the data permission rules and desensitization rules pre-integrated in the view parsing and running engine, and obtaining a secure processing dataset; and reorganizing and encapsulating the row and column data in the secure processing dataset into a nested JSON object structure according to the data format specifications defined by the target view model for front-end component binding, in order to generate target view data.

[0010] In one embodiment of this application, the received front-end submitted data is reverse-converted into domain model data according to the target view model. Specifically, this includes: parsing the structure of the front-end submitted data; wherein the front-end submitted data is a JSON object conforming to the output format of the target view model; traversing each attribute of the JSON object according to the field set defined in the target view model and its mapping relationship with the underlying data object; reverse-mapping the key name of each attribute to the corresponding standard field identifier in the domain model data, and converting the attribute value into the data type required by the standard field identifier, generating a key-value pair set containing the standard field identifier and the converted value; and grouping and structuring the key-value pair set according to the data object to which it belongs, forming domain model data, according to the association relationship defined in the target view data object structure.

[0011] In one embodiment of this application, an independent business entity engine service is invoked to perform business logic verification and consistent persistent storage of domain model data. Specifically, this includes: using domain model data and the target business entity identifier as input parameters, invoking the general data submission interface provided by the business entity engine service; within the business entity engine service, triggering data integrity verification logic bound to the target business entity identifier to check the non-emptiness of required fields in the domain model data, data format compliance, and validity of numerical ranges; within the business entity engine service, triggering state machine verification logic bound to the target business entity identifier to determine whether the requested persistence operation conforms to predefined state transition rules based on the current state field value in the domain model data; and after all verification logic passes, the business entity engine service atomically persists the domain model data to one or more corresponding physical database tables.

[0012] In one embodiment of this application, before receiving a form request from the front end, the method further includes: constructing and registering a view model, specifically including: providing a view model definition interface in an independent metadata management service to receive user selection operations on target business entities to determine the target business entity identifier; receiving user selection and association configuration operations on data objects through the view model definition interface to define the target view data object structure; receiving user selection and display attribute setting operations on each data object in the target view data object structure through the view model definition interface to define the field set; receiving user configuration operations on fields and corresponding operators that can be used for data filtering through the view model definition interface to define the filtering condition configuration; saving the complete view model metadata containing the target business entity identifier, target view data object structure, field set, and filtering condition configuration to the view model registration library, and assigning a unique view model identifier.

[0013] In one embodiment of this application, the method further includes: defining multiple differentiated view models for the same business entity, specifically including: in a metadata management service, initiating a new view model definition process for the same target business entity identifier; when defining the target view data object structure, configuring data object combinations or association depths different from existing view models to form differentiated data ranges; when defining the field set, selecting a subset of fields different from existing view models from all business fields corresponding to the target business entity identifier, or configuring different display attributes for the same fields; assigning a view model identifier different from existing view models to the new view model, and registering its metadata together with the view model registry, so that the front end can request different representations of the same business entity through different view model identifiers.

[0014] Secondly, embodiments of this application also provide a dynamic form construction device, the device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform a dynamic form construction method as described above.

[0015] Thirdly, embodiments of this application also provide a computer storage medium storing computer-executable instructions, which, when executed, implement a dynamic form construction method as described above.

[0016] The dynamic form construction method, device, and medium provided in this application have the following beneficial effects: By introducing a two-layer architecture of a view parsing and execution engine and a business entity engine, coupled with configurable view model definitions, complete decoupling of the front-end and back-end and full engineization of form construction are achieved. Its beneficial effects are as follows: First, by defining multiple differentiated view models for the same business entity, form views adaptable to multiple forms and terminals such as lists, details, PCs, and mobile devices can be quickly generated with just configuration, greatly improving customization capabilities and development efficiency; second, the view parsing and execution engine can dynamically construct optimal query statements based on the view model, ensuring on-demand data loading and efficient transmission, while integrating data permissions and data anonymization to guarantee security and performance; finally, all data submissions are converted back into domain model data by the engine and uniformly verified and persisted by the business entity engine, fundamentally eliminating the risk of scattered and inconsistent business logic, and significantly improving the maintainability and stability of the system. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart of a dynamic form construction method provided in this application embodiment; Figure 2 This is a schematic diagram of the internal structure of a dynamic form building device provided in an embodiment of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] This application provides a dynamic form construction method, device, and medium to solve the following technical problem: how to implement a highly decoupled, configurable, and driven dynamic form construction method to significantly improve development efficiency, view customization capabilities, and system maintainability.

[0020] The technical solutions proposed in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0021] Figure 1 This is a flowchart illustrating a dynamic form construction method provided in an embodiment of this application. Figure 1 As shown in the figure, the dynamic form construction method provided in this application embodiment specifically includes the following steps: Step 101: Based on the preset view parsing and running engine, receive form requests from the front end; wherein, the form request includes the view model identifier and the request type; the request type includes data query and data submission.

[0022] In this embodiment, the "preset view parsing and execution engine" refers to a software module that is loaded and runs on the server as an independent service or component during system deployment or startup. This engine is the core controller of the technical solution of this invention, responsible for coordinating all subsequent steps. It is typically a standalone microservice or embedded in the basic framework layer of the business system, providing a unified HTTP or RPC interface to the outside world. The "preset" characteristic of the engine means that its processing logic is general and independent of specific business, and its behavior is entirely driven by the "view model" configuration parsed in subsequent steps.

[0023] Furthermore, "form requests from the front end" refer to requests initiated by the user interface (such as a web browser or mobile app) to obtain or submit form data. Unlike traditional development where the front end calls specific API interfaces for specific functions, in this invention, all front end data interactions converge into requests to this unified view parsing and execution engine. The request payload must contain two key parameters: "view model identifier" and "request type".

[0024] Furthermore, the "view model identifier" is a globally unique string or code, such as "Employee_List_PC" or "Reimbursement_Detail_Mobile". Essentially, it's a frontend instruction to the engine declaring "which view I need" or "which view I want to submit data to". This identifier is assigned during view model registration and bound to a complete set of view configuration metadata. Frontend developers don't need to worry about the specific backend API addresses and parameters; they only need to pass in this identifier when needed.

[0025] Furthermore, the "Request Type" distinguishes between "fetching data" and "pushing data." Specifically, a "data query" request corresponds to scenarios such as initial loading, refreshing, pagination, and filtering of a front-end form; a "data submission" request corresponds to scenarios such as saving and submitting a form for approval. These two types will trigger completely different processing branches within the engine. The request may also carry other contextual information. For example, for a data query request, it may contain pagination parameters (page number, page size), sorting parameters, and dynamically passed filter values ​​based on the view model's filtering conditions; for a data submission request, it contains a JSON data packet conforming to the view model's defined format.

[0026] Step 102: Based on the view model identifier, retrieve and parse the predefined target view model to determine the metadata definition corresponding to the target view model; wherein, the metadata definition includes: target business entity identifier, target view data object structure, field set contained in the target view data object structure, and filter condition configuration.

[0027] In one embodiment of this application, based on the view model identifier, a predefined target view model is retrieved and parsed to determine the metadata definition corresponding to the target view model. Specifically, this includes: retrieving the corresponding view model configuration document from the view model registry based on the view model identifier, and parsing the view model configuration document to obtain the target business entity identifier; wherein, the target business entity identifier is used to point to an aggregate root composed of business fields; parsing the data object reference relationship defined in the view model configuration document to construct the target view data object structure; wherein, the target view data object structure is used to indicate the hierarchical relationship from the aggregate root main table to the associated data object table; parsing the field selection and display attribute configuration defined for each data object in the target view data object structure in the view model configuration document to form a field set, and parsing the filtering rules defined in the view model configuration document to form a filtering condition configuration.

[0028] Based on the above analysis process, it can be understood that after receiving a request, the engine first extracts the "view model identifier" and then accesses a central storage facility called the "view model registry." This registry can be a table in a relational database, a NoSQL document repository, or a configuration center, and it persistently stores all predefined view model configurations. The engine retrieves the configuration document of the "target view model" by using the identifier.

[0029] Furthermore, "parsing the predefined target view model" refers to deserializing the stored configuration document (which may be JSON, XML, or a specific DSL format) into an operable structured object in the engine's memory. This process is similar to a compiler reading source code. The purpose of parsing is to extract the "metadata definition," a crucial data structure, from which all subsequent operations depend.

[0030] In this embodiment, the core components of metadata definition include: 1. Target Business Entity Identifier: This is a reference to a core business concept. For example, the identifier might be "Employee" or "PurchaseOrder." It indicates which business domain object this view model ultimately serves. This identifier is used to associate with the correct "Business Entity Engine" service in subsequent steps.

[0031] 2. Target View Data Object Structure: This structure defines which "data objects" this view needs to retrieve from the database, and the relationships between these objects. A "data object" typically corresponds to a physical table or a logical view in the database. For example, for an "Employee Details" view, its structure might be defined as follows: starting from the core EMPLOYEE (employee master table), it joins the DEPARTMENT (department table) to obtain the department name, and then joins the JOB (job title table) to obtain the job title. This structure is a tree-like or graph-like model that describes the data source path. It determines which table JOIN operations need to be performed when dynamically generating SQL subsequently.

[0032] 3. Field Set: This is a more granular definition based on the "Target View Data Object Structure". It precisely specifies which fields (columns) need to be retrieved for each data object in the defined data object structure, and how these fields should be displayed on the front end. For example, for the EMPLOYEE table, only the EMP_ID (employee ID), EMP_NAME (name), and EMAIL (email address) fields might be selected, while the SALARY (salary) field is not selected; for the associated DEPARTMENT table, only the DEPT_NAME (department name) field might be selected. In addition, the field set also includes display attributes, such as the field's display label, the component type in the front-end form (e.g., input box, dropdown selector, date picker), whether it is read-only, whether it is required, validation rules, etc. These attributes do not directly participate in back-end data queries, but are returned to the front end as part of the metadata, guiding the front end on how to render form controls.

[0033] 4. Filtering Condition Configuration: This configuration defines which fields front-end users are allowed to filter data based on in this view, and the filtering methods. For example, you can configure filtering to allow by "Employee Name" (fuzzy match), by "Start Date" (range filter), and by "Department" (exact match). The configuration defines the data object and field name corresponding to the filter fields, as well as the allowed operators (such as =, >, <, LIKE, BETWEEN). When a data query request is initiated, the front-end can pass in the specific filter values, and the engine will dynamically generate the WHERE clause in the SQL based on them.

[0034] Step 103: When the request type is data query, dynamically construct a structured query language statement based on the target view data object structure, field set and filter condition configuration to obtain the original dataset from the database, and aggregate and transform the original dataset according to the target view model to generate and return target view data that meets the front-end rendering requirements.

[0035] This step is the core technical step in processing data query requests, embodying the essence of "dynamic construction." It aims to generate optimized database queries, avoiding redundant data reading and transmission. Specifically, the engine first determines the request type as a "data query," and then uses the parsed metadata to begin constructing the SQL statement.

[0036] In one embodiment of this application, a structured query language statement is dynamically constructed based on the target view data object structure, field set, and filter condition configuration. Specifically, this includes: determining the main data object table to be queried and one or more subordinate data object tables derived through association relationships based on the target view data object structure; selecting a list of target field names from the main data object table and one or more subordinate data object tables based on the field set; combining the filter fields, operators, and passed filter values ​​defined in the filter condition configuration into one or more query condition expressions; and automatically adding join clauses between the main data object table and one or more subordinate data object tables based on database association relationships, and integrating the target field name list with one or more query condition expressions to dynamically construct a complete structured query language statement.

[0037] Based on the above construction process, it can be understood that the construction process specifically includes the following steps: First, the engine analyzes the data object structure to determine the query scope. It traverses the tree-like model of the "target view data object structure." The root node of the tree is typically the master data object (master table) of the business entity. Based on the relationships defined in the structure (such as foreign keys), the engine identifies all dependent data objects (related tables) that need to be involved. For example, if the structure is defined as: Employee table -> (belonging to) Department table -> (located in) Office location table, the engine will determine that it needs to query the EMPLOYEE, DEPARTMENT, and LOCATION tables.

[0038] Secondly, the target columns are selected based on the field set. The engine iterates through each field defined in the field set that needs to be displayed, finding the data object to which that field belongs. Then, these field names are converted into column names in the database, and aliases are assigned to them as possible (to avoid column name conflicts when joining multiple tables), forming a final "list of target field names" to be queried. For example, the final generated SELECT clause might be: SELECT e.EMP_ID, e.EMP_NAME, d.DEPT_NAME, l.CITY_NAME...

[0039] Next, the filter conditions are integrated to form query constraints. The engine checks the "filter condition configuration". If the front end provides specific filter values ​​in the request (e.g., departmentId=10, hireDateStart='2023-01-01'), the engine combines these values ​​with the fields and operators in the configuration to generate SQL WHERE clause fragments. For example, if filtering by department ID is configured (operator =), and the value 10 is passed, then d.DEPT_ID=10 is generated. If filtering by start date range is configured (operator BETWEEN), and start and end dates are passed, then e.HIRE_DATEBETWEEN'2023-01-01'AND'2023-12-31' is generated. These fragments will be logically combined (AND / OR) into a complete WHERE condition.

[0040] Finally, the engine automates the construction and assembly of the complete SQL statement. This is the most technically valuable step. Based on predefined relationships in the data object structure (such as EMPLOYEE.DEPT_ID=DEPARTMENT.ID), the engine automatically generates the correct table join (JOIN) statements in the FROM and JOIN parts of the SQL. It intelligently determines the join type (such as INNERJOIN, LEFTJOIN) to ensure that the correct result set is returned even when related data is missing (for example, employees may not be assigned to departments; using LEFTJOIN ensures that employee records are still retrieved). Ultimately, the engine dynamically concatenates the SELECT, FROM / JOIN, WHERE, and possible pagination and sorting instructions (from request parameters) into a complete, efficient SQL statement without redundant fields or table joins.

[0041] Furthermore, executing this dynamically generated SQL statement returns a "raw dataset" from the database. This dataset is a flattened result set containing all selected columns from multiple related tables, typically presented in rows. It has completed the initial data association and filtering, preparing it for the next step of fine-tuning.

[0042] It should be noted that while the "raw dataset" obtained from the database contains the required data, its format is database-oriented and flat, and may contain sensitive or redundant fields that the view does not need. Therefore, the raw dataset still needs to be aggregated and transformed.

[0043] In one embodiment of this application, the original dataset is aggregated and transformed according to the target view model to generate and return target view data that meets the requirements of front-end rendering. Specifically, this includes: performing field pruning on the original dataset according to the target view data object structure and field set, filtering out redundant field data that is not referenced by the target view model, and obtaining a pruned dataset; performing real-time access control and sensitive information transformation processing on specific rows or columns of data in the pruned dataset according to the data permission rules and desensitization rules pre-integrated in the view parsing and running engine, and obtaining a secure processing dataset; and reorganizing and encapsulating the row and column data in the secure processing dataset into a nested JSON object structure according to the data format specifications defined by the target view model for front-end component binding, in order to generate target view data.

[0044] Based on the above processing steps, it's understandable that the first step in aggregation and transformation is field pruning. The engine again compares the data against the "field set," precisely extracting the values ​​of the fields explicitly required by the view model from each row of the original dataset, discarding any other unreferenced field data. This ensures minimal data transmission over the network, adhering to the principle of "on-demand transmission."

[0045] Further, the second step is data security and desensitization processing. This is an ability deeply integrated in the present invention. The view parsing and running engine has a built-in or accessible set of data permission and desensitization rules. Before the data is returned, the engine will apply these rules in real time. For example, according to the role of the currently logged-in user, perform row-level permission filtering on the "salary" field (certain users cannot see the salary records of specific employees), or perform column-level desensitization on the "ID number" field (displayed as 110101****1234). These processes are completed at the last moment before the data flows out of the engine, ensuring the centralization and enforcement of security policies.

[0046] Further, the third step is data structure conversion and encapsulation. This is the key to converting the database result set into a front-end friendly format. The front-end usually expects nested JSON objects to reflect the business hierarchical relationship of the data, rather than a flat table. The engine performs a reverse "aggregation" operation according to the association relationships defined in the "target view data object structure". It "folds" the fields in the flat data rows back into a nested object structure according to the data objects they belong to. For example, a row of flat data [empId: 1001, empName: 'Zhang San', deptId: 10, deptName: 'R & D Department'], after conversion, will form the following JSON object: {"id": 1001, "name": "Zhang San", "department": {"id": 10, "name": "R & D Department"}}. This conversion allows the front-end to directly access the data through the object property chain (such as employee.department.name), greatly simplifying the front-end code.

[0047] Finally, the engine encapsulates the data after trimming, security processing, and structure conversion, together with the metadata of the field display attributes (such as component type, label, etc.) in the view model, into a structured response package, that is, the "target view data", and returns it to the front-end. After receiving it, the front-end gets both the values required for rendering and the instructions on how to render these values, and can generate the form interface completely automatically.

[0048] Step 104, when the request type is data submission, according to the target view model, reverse-convert the front-end submitted data received into domain model data, and call the independent business entity engine service to perform business logic verification and consistent persistent storage on the domain model data.

[0049] In this embodiment, when the request type is data submission, first, the data submitted by the front-end based on a specific view format needs to be "translated" back into a standardized format that the system core business domain can understand, realizing the reverse mapping from the "view layer" to the "domain layer".

[0050] In one embodiment of this application, the received front-end submitted data is reverse-converted into domain model data according to the target view model. Specifically, this includes: parsing the structure of the front-end submitted data; wherein the front-end submitted data is a JSON object conforming to the output format of the target view model; traversing each attribute of the JSON object according to the field set defined in the target view model and its mapping relationship with the underlying data object; reverse-mapping the key name of each attribute to the corresponding standard field identifier in the domain model data, and converting the attribute value into the data type required by the standard field identifier, generating a key-value pair set containing the standard field identifier and the converted value; and grouping and structuring the key-value pair set according to the data object to which it belongs, forming domain model data, according to the association relationship defined in the target view data object structure.

[0051] Based on the above conversion process, it can be understood that the data submitted by the front-end (i.e., "front-end submitted data") is generated after the user fills in or modifies the form on the form interface, and its structure is a nested JSON format. However, this structure is designed for the convenience of front-end display and interaction and is not directly suitable for back-end business logic processing and database persistence. For example, the front-end submitted {"name":"Zhang San","department":{"id":10}} needs to be converted into a format more suitable for database operations, which may be a flat data structure that explicitly indicates EMP_NAME='Zhang San', DEPT_ID=10.

[0052] Furthermore, the "reverse transformation" process is exactly the opposite of the data aggregation transformation in step 103, and can be viewed as a "de-aggregation" or "flattening" process. The engine parses the JSON object submitted by the front end based on the same "target view model" metadata (especially the field set and its mapping relationship with the underlying data objects).

[0053] Furthermore, the engine performs a deep traversal of every property of this JSON object. For each property, it needs to complete two key mappings: First, field identifier mapping, which reverses the property name used by the front end (e.g., "department.id") and maps it back to the standard field identifier (e.g., "DEPT_ID") within the domain model that corresponds to the database column. This mapping relationship is established when the view model is defined. Second, data type conversion, which converts the JSON primitive types such as strings and numbers passed by the front end into the specific data types expected by the domain model. For example, converting date strings to java.util.Date or LocalDateTime objects, and converting enumeration value strings to corresponding enumeration constants.

[0054] Further, after traversal and mapping, the engine obtains an intermediate "key-value pair set," where the keys are standard domain model field identifiers, and the values ​​are type-converted values. Next, the engine groups these key-value pairs according to the "target view data object structure" and their respective data objects. For example, all fields belonging to the EMPLOYEE table (such as EMP_NAME, EMP_EMAIL) are grouped together, and all fields belonging to the associated ADDRESS table (such as ADDR_PROVINCE, ADDR_CITY) are grouped together. Finally, these groups are organized into a structured "domain model data" object. This object accurately reflects the complete state changes of the business entity and its associated objects, serving as the correct input for backend business logic processing.

[0055] In this embodiment, after the received front-end submitted data is converted into domain model data, an independent business entity engine service is invoked to perform business logic verification and consistent persistent storage of the domain model data.

[0056] In one embodiment of this application, an independent business entity engine service is invoked to perform business logic verification and consistent persistent storage of domain model data. Specifically, this includes: using domain model data and the target business entity identifier as input parameters, invoking the general data submission interface provided by the business entity engine service; within the business entity engine service, triggering data integrity verification logic bound to the target business entity identifier to check the non-emptiness of required fields in the domain model data, data format compliance, and validity of numerical ranges; within the business entity engine service, triggering state machine verification logic bound to the target business entity identifier to determine whether the requested persistence operation conforms to predefined state transition rules based on the current state field value in the domain model data; and after all verification logic passes, the business entity engine service atomically persists the domain model data to one or more corresponding physical database tables.

[0057] Based on the above processing, it can be understood that the "Business Entity Engine Service" is a service deployed independently or existing as a core component. It encapsulates all the core business rules and persistence logic for a specific business entity (such as an employee or an order). It is the sole authoritative entry point for operating the domain model. Its "independence" ensures high cohesion and reusability of the business logic, without depending on any specific front-end view. The invocation process is typically conducted through a well-defined general interface, such as submitEntity(entityId, domainModelData). The engine passes in the "target business entity identifier" and the transformed "domain model data" as parameters.

[0058] Furthermore, during the invocation, a series of rigorous validation and persistence operations are triggered within the business entity engine: First, perform data integrity verification: check whether all required fields required by business rules have been provided with values, whether the values ​​are within a reasonable range (e.g., age cannot be negative), and whether the string format meets the requirements (e.g., email format).

[0059] Secondly, perform state machine and process validation: For business entities with state transitions (such as orders with "pending - shipped - completed" status), validate whether the current request modification operation (such as changing from "pending" to "shipped") conforms to predefined state transition rules. For example, prohibit the reactivation of canceled orders.

[0060] Finally, perform complex business rule validation: execute complex rules that may involve multiple fields or even multiple related entities. For example, when creating an expense report, validate that the total reimbursement amount does not exceed the project budget balance; or when adjusting inventory, validate that the quantity issued does not exceed the current inventory level.

[0061] Furthermore, the business entity engine only initiates the persistence operation after all validations have passed. It atomically writes the structured "domain model data" to one or more related database tables. This write process is typically completed within a single database transaction, ensuring data consistency (e.g., saving order header information and order detail rows either all succeeds or all fails). Upon successful persistence, the business entity engine returns a success result (which may include generated primary keys, etc.) to the view resolution engine, which then sends a success signal to the front end.

[0062] In this embodiment, it should also be noted that the powerful flexibility and high efficiency of the method of the present invention are rooted in the configurability of the "view model".

[0063] In one embodiment of this application, before receiving a form request from the front end, the method further includes: constructing and registering a view model, specifically including: providing a view model definition interface in an independent metadata management service to receive user selection operations on target business entities to determine the target business entity identifier; receiving user selection and association configuration operations on data objects through the view model definition interface to define the target view data object structure; receiving user selection and display attribute setting operations on each data object in the target view data object structure through the view model definition interface to define the field set; receiving user configuration operations on fields and corresponding operators that can be used for data filtering through the view model definition interface to define the filtering condition configuration; saving the complete view model metadata containing the target business entity identifier, target view data object structure, field set, and filtering condition configuration to the view model registration library, and assigning a unique view model identifier.

[0064] Based on the above view model construction process, it can be understood that this service provides a graphical "view model definition interface". Users first need to select a "target business entity," such as "Reimbursement" from a dropdown list. This selection determines the business affiliation of this view model.

[0065] Next, users "draw" the data object structure on the interface through interactive methods such as dragging and dropping, and checking boxes. For example, from the list of database tables associated with entities, users can check REIMBURSEMENT_MAIN (the main expense report table) and REIMBURSEMENT_ITEM (the expense report details table) and establish a parent-child relationship (one-to-many) between the two. This defines the source skeleton of the data.

[0066] Then, the user can further select the specific fields to be displayed on the front end for the selected data object. For the REIMBURSEMENT_MAIN table, fields such as APPLY_DATE (application date), TOTAL_AMOUNT (total amount), and STATUS (status) might be selected; for the REIMBURSEMENT_ITEM table, fields such as ITEM_TYPE (fee type), AMOUNT (amount), and DESCRIPTTION (description) might be selected. Simultaneously, the display attributes for each field on the front end can be set, such as setting the component type of the STATUS field to "read-only label," setting ITEM_TYPE to a "dropdown selection box," and binding it to a dictionary data source for the fee type.

[0067] Users can further configure filter criteria. For example, they can specify the "Application Date" and "Status" fields as filters on the list page and set their default operators ("between" for date and "equal to" for status).

[0068] Furthermore, once all configurations are complete, the user saves the changes. The metadata management service serializes this configuration (target business entity identifier, data object structure, field set, filter condition configuration, etc.) into a complete configuration document and persists it to the "View Model Registry". During storage, the system automatically generates or the user specifies a unique "View Model Identifier," such as "Reimb_List_For_Applicant" (Reimbursement List - Applicant View). At this point, a new, engine-driven view model is created. The frontend only needs to use this identifier in requests to obtain or submit form data and interaction logic that conforms to the configuration definition. This configurable development model reduces the time to respond to new view requirements (such as quickly creating a simplified reimbursement details page for mobile devices) from days of coding to minutes of configuration, achieving an order-of-magnitude improvement in development efficiency.

[0069] In this embodiment, within the same "metadata management service," users can initiate multiple processes to create view models for the same "target business entity identifier" (e.g., "Employee"). Each creation generates a "differentiated view model" that serves different scenarios, terminals, and user roles by configuring different parameters.

[0070] In one embodiment of this application, the method further includes: defining multiple differentiated view models for the same business entity, specifically including: in a metadata management service, initiating a new view model definition process for the same target business entity identifier; when defining the target view data object structure, configuring data object combinations or association depths different from existing view models to form differentiated data ranges; when defining the field set, selecting a subset of fields different from existing view models from all business fields corresponding to the target business entity identifier, or configuring different display attributes for the same fields; assigning a view model identifier different from existing view models to the new view model, and registering its metadata together with the view model registry, so that the front end can request different representations of the same business entity through different view model identifiers.

[0071] It should be noted that the dimensions of differentiation are mainly reflected in: 1. Data Scope Differentiation: When defining the "Target View Data Object Structure", select different combinations of data objects. For example, the "Employee Basic Information View" may only be associated with the EMPLOYEE main table and the DEPARTMENT table; while the "Employee Complete Profile View" may be associated with multiple subsidiary tables such as EDUCATION (educational background) and WORK_EXPERIENCE (work experience) in addition to the above two tables, forming a deeper and broader data relationship tree.

[0072] 2. Field Set and Display Differentiation: Select different subsets from the entire pool of business fields owned by the business entity for different view models. For example, the "HR Management View" may include sensitive fields such as Salary and Performance Rating; while the "Department Address Book View" only includes public fields such as Name, Employee ID, Email, and Phone Number. Furthermore, even the same field can be configured with different display attributes, such as displaying the "Personal Profile" field as a rich text editor on the PC details page, while completely hiding it or only displaying a summary on the mobile list page.

[0073] 3. Differentiation in Interaction and Filtering: Different view models can be configured with completely different filtering conditions. List page views are usually configured with rich filtering options to facilitate queries; while a dedicated data report view may have fixed filtering conditions for a specific range, or only allow filtering by time period.

[0074] Understandably, each such configuration generates a new configuration document with a unique "view model identifier" and registers it in the library. For example, for the "Employee" entity, multiple view models can exist simultaneously, such as "Employee_SimpleList_Mobile", "Employee_Detail_PC", and "Employee_HRAdmin_List". The front-end application can choose to call different view model identifiers based on the current page scenario. For example, when opening the employee list on a mobile device, it requests "Employee_SimpleList_Mobile"; when opening a detailed profile page for a specific employee on a PC, it requests "Employee_Detail_PC".

[0075] This mechanism makes the concept of "one business entity, multiple presentation forms" easily realized. It perfectly solves the pain point of traditional development that requires writing independent interfaces and pages for each presentation form. Through the diversity of configurations, it naturally supports multi-platform adaptation, role-based views, and scenario-based interactions, raising customization capabilities to an unprecedented level, while maintaining the absolute unity and stability of the core backend business logic.

[0076] The above are embodiments of the method proposed in this application. Based on the same inventive concept, embodiments of this application also provide a dynamic form building device, the structure of which is as follows: Figure 2 As shown.

[0077] Figure 2 This is a schematic diagram of the internal structure of a dynamic form building device provided in an embodiment of this application. Figure 2 As shown, the device includes: At least one processor 201; And a memory 202 that is communicatively connected to at least one processor; The memory 202 stores instructions executable by at least one processor, which are executed by at least one processor 201 to enable at least one processor 201 to: Based on a pre-defined view parsing engine, the system receives form requests from the front end. Each form request includes a view model identifier and a request type. Request types include data query and data submission. Based on the view model identifier, the system retrieves and parses a predefined target view model to determine its corresponding metadata definition. This metadata definition includes: the target business entity identifier, the target view data object structure, the set of fields contained in the target view data object structure, and the filter condition configuration. When the request type is a data query, the system dynamically constructs a structured query language statement based on the target view data object structure, field set, and filter condition configuration to retrieve the original dataset from the database. It then aggregates and transforms the original dataset according to the target view model, generating and returning target view data that meets the front end rendering requirements. When the request type is a data submission, the system reverse-engineers the received front end submission data into domain model data based on the target view model and calls an independent business entity engine service to perform business logic verification and consistent persistent storage of the domain model data.

[0078] Some embodiments of this application provide corresponding to Figure 1 A computer storage medium storing computer-executable instructions, wherein the computer-executable instructions are configured as follows: Based on a pre-defined view parsing engine, the system receives form requests from the front end. Each form request includes a view model identifier and a request type. Request types include data query and data submission. Based on the view model identifier, the system retrieves and parses a predefined target view model to determine its corresponding metadata definition. This metadata definition includes: the target business entity identifier, the target view data object structure, the set of fields contained in the target view data object structure, and the filter condition configuration. When the request type is a data query, the system dynamically constructs a structured query language statement based on the target view data object structure, field set, and filter condition configuration to retrieve the original dataset from the database. It then aggregates and transforms the original dataset according to the target view model, generating and returning target view data that meets the front end rendering requirements. When the request type is a data submission, the system reverse-engineers the received front end submission data into domain model data based on the target view model and calls an independent business entity engine service to perform business logic verification and consistent persistent storage of the domain model data.

[0079] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments for IoT devices and media are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0080] The systems, media, and methods provided in this application are one-to-one correspondences. Therefore, the systems and media also have similar beneficial technical effects as their corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the systems and media will not be repeated here.

[0081] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0082] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0083] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0084] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0085] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0086] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0087] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0088] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0089] The above are merely embodiments of this application and are not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for constructing dynamic forms, characterized in that, The method includes: Based on a preset view parsing and execution engine, it receives form requests from the front end; wherein, the form request includes a view model identifier and a request type; the request type includes data query and data submission; Based on the view model identifier, a predefined target view model is retrieved and parsed to determine the metadata definition corresponding to the target view model; wherein, the metadata definition includes: target business entity identifier, target view data object structure, the set of fields contained in the target view data object structure, and filter condition configuration; When the request type is a data query, a structured query language statement is dynamically constructed based on the target view data object structure, the field set, and the filter condition configuration to obtain the original dataset from the database, and the original dataset is aggregated and transformed according to the target view model to generate and return target view data that meets the front-end rendering requirements. When the request type is data submission, the received front-end submitted data is converted into domain model data according to the target view model, and an independent business entity engine service is called to perform business logic verification and consistent persistent storage on the domain model data.

2. The dynamic form construction method according to claim 1, characterized in that, Based on the view model identifier, a predefined target view model is retrieved and parsed to determine the metadata definition corresponding to the target view model, specifically including: From the view model registry, the corresponding view model configuration document is retrieved based on the view model identifier, and the view model configuration document is parsed to obtain the target business entity identifier; wherein, the target business entity identifier is used to point to an aggregate root composed of business fields; The data object reference relationships defined in the view model configuration document are parsed to construct the target view data object structure; wherein, the target view data object structure is used to indicate the hierarchical relationship from the aggregate root master table to the associated data object table; The field selection and display attribute configurations defined for each data object within the target view data object structure in the view model configuration document are parsed to form the field set, and the filtering rules defined in the view model configuration document are parsed to form the filtering condition configuration.

3. The dynamic form construction method according to claim 1, characterized in that, Based on the target view data object structure, the field set, and the configured filtering conditions, a structured query language statement is dynamically constructed, specifically including: Based on the target view data object structure, determine the main data object table that needs to be queried and one or more subordinate data object tables derived through association relationships; Based on the set of fields, select a list of target field names from the master data object table and the one or more subordinate data object tables; Combine the filter fields, operators, and passed filter values ​​defined in the filter condition configuration into one or more query condition expressions; Based on the database relationships, a join clause is automatically added between the master data object table and the one or more subordinate data object tables, and the list of target field names is integrated with the one or more query condition expressions to dynamically construct a complete structured query language statement.

4. The dynamic form construction method according to claim 1, characterized in that, The original dataset is aggregated and transformed according to the target view model to generate and return target view data that meets the front-end rendering requirements, specifically including: Based on the target view data object structure and the field set, the original dataset is pruned to remove redundant field data that is not referenced by the target view model, resulting in a pruned dataset. Based on the data permission rules and desensitization rules pre-integrated in the view parsing engine, real-time access control and sensitive information transformation processing are performed on specific rows or columns of data in the cropped dataset to obtain a securely processed dataset. According to the data format specification for front-end component binding defined in the target view model, the row and column data in the security processing dataset are reorganized and encapsulated into a nested JSON object structure to generate the target view data.

5. The dynamic form construction method according to claim 1, characterized in that, Based on the target view model, the received front-end submitted data is converted back into domain model data, specifically including: Parse the structure of the data submitted by the front end; wherein the data submitted by the front end is a JSON object that conforms to the output format of the target view model; Based on the set of fields defined in the target view model and their mapping relationship with the underlying data object, traverse each property of the JSON object; The key name of each attribute is reverse-mapped to the corresponding standard field identifier in the domain model data, and the attribute value is converted into the data type required by the standard field identifier, generating a key-value pair set containing the standard field identifier and the converted value; Based on the relationships defined in the target view data object structure, the key-value pair set is grouped and structured according to its data object to form the domain model data.

6. The dynamic form construction method according to claim 1, characterized in that, The independent business entity engine service is invoked to perform business logic verification and consistent persistent storage of the domain model data, specifically including: The domain model data and the target business entity identifier are used as input parameters to call the general data submission interface provided by the business entity engine service. Within the business entity engine service, data integrity verification logic bound to the target business entity identifier is triggered to check the non-emptiness of required fields in the domain model data, data format compliance, and validity of numerical range. Within the business entity engine service, state machine verification logic bound to the target business entity identifier is triggered. Based on the current state field value in the domain model data, it is determined whether the persistent operation requested conforms to the predefined state transition rules. After all verification logic passes, the business entity engine service atomically persists the domain model data to one or more corresponding physical database tables.

7. The dynamic form construction method according to claim 1, characterized in that, Before receiving the form request from the front end, the method further includes: Building and registering view models specifically includes: In the independent metadata management service, a view model definition interface is provided to receive user selection operations on target business entities in order to determine the identifier of the target business entity; The view model definition interface receives user selection and association configuration operations for data objects to define the structure of the target view data object. The view model definition interface receives user input on the selection of required fields and the setting of display attributes for each data object in the target view data object structure, thereby defining the field set. The view model definition interface receives user configuration operations for fields and corresponding operators that can be used for data filtering, in order to define the filtering condition configuration. Save the complete view model metadata, including the target business entity identifier, the target view data object structure, the field set, and the filter condition configuration, to the view model registry, and assign a unique view model identifier.

8. The dynamic form construction method according to claim 7, characterized in that, The method further includes: Define multiple differentiated view models for the same business entity, specifically including: In the metadata management service, a process for creating a new view model definition is initiated for the same target business entity identifier; When defining the target view data object structure, configure data object combinations or association depths that are different from those of existing view models to form a differentiated data range; When defining the field set, select a subset of fields that are different from the existing view model from all the business fields corresponding to the target business entity identifier, or configure different display attributes for the same field; Assign a view model identifier that is different from the existing view model to the new view model, and register its metadata together with the view model registry, so that the front end can request different representations of the same business entity through different view model identifiers.

9. A dynamic form creation device, characterized in that, The device includes: At least one processor; And, a memory communicatively connected to the at least one processor; The memory stores instructions that can be executed by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform a dynamic form construction method as described in any one of claims 1-8.

10. A computer storage medium storing computer-executable instructions, characterized in that, When the computer-executable instructions are executed, a dynamic form construction method as described in any one of claims 1-8 is implemented.

Images