Component data processing method, system and equipment supporting multi-type expansion

Abstract

The invention relates to the technical field of data processing, in particular to a component data processing method, system and equipment supporting multi-type expansion, and the method comprises the steps that a basic data structure is defined, the basic data structure comprises a basic field and an expansion attribute field, and the basic field comprises a component type; receiving component data which is submitted by the front end and is represented based on the basic data structure; analyzing a component type in the component data; and according to the component type, routing the component data to a corresponding component processor based on a preset policy factory, and processing and storing the component data through the component processor. Thus, through the scheme provided by the invention, remarkable comprehensive beneficial effects can be generated in the aspects of unifying data processing, facilitating function extension, improving development efficiency and guaranteeing system stability.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically to a component data processing method, system, and device that supports multiple types of extensions. Background Technology

[0002] In existing technologies, especially in product resource management scenarios of IoT platforms, the front-end and back-end need to frequently interact and process various types of data components, such as strings, numbers, files, certificates, keys, and firmware. Traditional data processing solutions typically define independent data structures and interaction interfaces for each component type, leading to the following prominent problems in the system: First, the numerous and disorganized front-end and back-end interfaces, coupled with a lack of unified data structures, result in high development and maintenance costs. Second, data validation logic is scattered across various business modules, making centralized maintenance and expansion difficult and prone to security vulnerabilities. Third, adding a new component type often requires simultaneous modifications to core business logic, database structure, and front-end and back-end interfaces, severely violating the open / closed principle of software design, leading to difficult system expansion and high iteration risks. Finally, the highly coupled logic of data processing, validation, storage, and serialization results in a rigid system that struggles to adapt to rapid changes in business requirements.

[0003] Therefore, there is an urgent need in this field for a data processing solution that can unify data interaction formats, achieve automated verification, support flexible expansion, and be fully decoupled, so as to improve the development efficiency, robustness, and maintainability of software systems. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a component data processing method, system and device that supports multiple types of extensions, so as to overcome the problems of complex interfaces, difficult extension and logical coupling in the processing of multiple types of data components in current complex software platforms such as the Internet of Things.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: Firstly, this application provides a component data processing method that supports multiple types of extensions, including: Define a basic data structure, which includes basic fields and extended attribute fields, wherein the basic fields include component types; Receive component data submitted by the front end based on the aforementioned basic data structure; Parse the component type in the component data; Based on the component type, the component data is routed to the corresponding component processor using a preset strategy factory, and the component processor processes and stores the component data.

[0006] Furthermore, in some embodiments of this application, the basic fields include: component unique identifier, display label, data version, component type, extended field flag, required field flag, removed item flag, edit item keyword flag, and edit item type flag; The extended attribute fields include: basic extended attributes and special extended attributes; The basic extended attributes include single data values ​​and array data values, used to identify and store numerical values ​​of string, number, and Boolean data; the special extended attributes include type-specific fields, used to identify and store specific fields of file, certificate, key, and firmware type data.

[0007] Furthermore, in some embodiments of this application, based on the component type, the component data is routed to the corresponding component processor according to a preset strategy factory, and the component processor processes and stores the component data, including: The component processor calls a preset verifier to verify the component data. If the verification passes, the component processor calls a preset serializer to serialize the component data into a preset database format. The component processor uses a preset storage adapter to insert the serialized data into the product resource component table of the database.

[0008] Furthermore, in some embodiments of this application, the verifier, serializer, and storage adapter are encapsulated in corresponding component processors.

[0009] Furthermore, in some embodiments of this application, it also includes: Receive the front end's request to display stored component data, and query the database to retrieve the corresponding target component data; Based on the component type in the target component data, the strategy factory routes the target component data to the corresponding component processor; The component processor calls the deserializer to deserialize the target component data into the echo format required by the front end and return it to the front end.

[0010] Furthermore, in some embodiments of this application, it also includes: Receive user requests to add new component types; Register the component processor corresponding to the newly added component type in the policy factory, and configure the corresponding validator, serializer and storage adapter for the registered component processor.

[0011] Furthermore, in some embodiments of this application, the component data submitted by the front end based on the underlying data structure is in JSON format.

[0012] Secondly, this application also provides a component data processing system that supports multiple types of extensions, including: The front end is used to generate component data based on the underlying data structure representation; The server is used to define modules and basic data structures, including basic fields and extended attribute fields. The basic fields include component type. The server parses the component type in the component data and routes the component data to the corresponding component processor based on the component type and a preset strategy factory. The component processor then processes the component data and stores it in the database. A database is used to store the data processed by the component processor.

[0013] Furthermore, in some embodiments of this application, the server is also configured to receive a front-end request for echoing stored component data, query and obtain the target component data corresponding to the echoing request, convert the target component data into the echoing format required by the front-end, and return it to the front-end.

[0014] Thirdly, this application also provides a component data processing device that supports multiple types of expansion, including a processor and a memory, wherein the processor is connected to the memory: The processor is used to call and execute the program stored in the memory; The memory is used to store the program, which is at least used to execute the above-described component data processing method that supports multiple types of extensions.

[0015] The beneficial effects of this plan include at least the following: By defining a unified basic data structure as the data interaction contract for all components, the problem of inconsistent data structures and numerous and messy front-end and back-end interfaces in traditional solutions is fundamentally solved. This achieves the standardization of data interaction formats and significantly reduces the complexity of system integration and development and maintenance costs.

[0016] By adopting the strategy pattern and layered architecture design, the component processing logic is encapsulated by type. When a new component type needs to be added, only the corresponding component processor needs to be added and registered. There is no need to modify the core routing logic, business code, database structure and existing interfaces. Strictly following the open / closed principle, it greatly improves the system's scalability, reduces the risk and cost of function iteration, and the clear module boundaries also greatly improve the maintainability of the code.

[0017] By cohesively integrating type-specific validation rules and serialization / deserialization logic into their respective component processors, data validation and format conversion are automated and standardized, avoiding the fragmentation and redundant development of validation logic and improving the accuracy of data processing and overall execution efficiency.

[0018] Based on a layered architecture (such as a front-end submission layer, service processing layer, validation layer, and storage layer), different concerns in data processing are separated, which effectively reduces the coupling between system modules. This makes modifications to each part of the system more independent and secure, and the overall architecture is more flexible and robust, better able to adapt to changes in requirements. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the component data processing method supporting multiple types of extensions provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating a component data processing method supporting multiple types of extensions provided in another embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a component data processing system supporting multiple types of extensions provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the structure of a component data processing device that supports multiple types of extensions, as provided in an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be described in detail below. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other implementation methods obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0022] Figure 1 This is a flowchart illustrating the component data processing method supporting multiple types of extensions provided in an embodiment of the present invention. Please refer to [link / reference]. Figure 1 This embodiment may include the following steps: S101. Define the basic data structure.

[0023] The basic data structure includes basic fields and extended attribute fields, with the basic fields including component types.

[0024] Specifically, in some embodiments, a unified basic data structure is defined as the basic contract for the interaction of all component data (various heterogeneous business data objects such as strings, numbers, files, certificates, keys, and firmware that interact between the front end and the back end in scenarios such as product resource management on IoT platforms). This structure contains basic fields shared by all components, and supports the storage and interaction of specific types of data through extended attribute fields. The basic fields include component unique identifier (key), display label (label), data version (version), component type (fieldType), extended field flag (extFieldFlag), mandatory field flag (mandatoryFlag), removed item flag (removeItemFlag), edit item key flag (editItemKeyFlag), and edit item type flag (editItemTypeFlag). Through the above settings, we ensure that the basic format of all component data is consistent. Extended attribute fields include basic extended attributes and special extended attributes. Basic extended attributes (Attribute) contain single data values ​​(values) and array data values ​​(values), used to support data storage of basic data types such as strings, numbers, and booleans. Meanwhile, for special data types such as files, certificates, keys, and firmware, corresponding special extended attributes (such as CDFileAttribute) are designed, adding type-specific fields (such as file identifier pid, version number versionNumber, certificate number certificationNumber, etc.) to the basic extended attributes, enabling flexible expansion of data for special data types. S102. Receive component data submitted by the front end based on the basic data structure representation.

[0025] S103, Parse the component type in the component data.

[0026] S104. Based on the component type, the component data is routed to the corresponding component processor according to the preset strategy factory, and the component data is processed and stored in the database through the component processor.

[0027] Specifically, the component data is processed by the component processor corresponding to the component type of the component data, such as validation, serialization and storage, to realize the input of front-end data into the database.

[0028] Understandably, corresponding to the above basic data structure, when component data is entered into the database, the data entry format is divided into a default unified format and a special entry format.

[0029] The default unified format is based on the aforementioned unified basic data structure and is applicable to component data of basic types such as strings, numbers, and booleans (including only basic fields and basic extended attributes of extended attribute fields). The special inbound format is for special types of components such as files (such as CD files), firmware, keys, and certificates. Based on the default unified format, it supplements type-specific fields through special extended attributes of extended attribute fields to ensure the complete storage of component data of special types. For example, in the inbound format of component data of CD file type, the type-specific fields in the special extended attributes include pid, vid, cdPid, versionNumber, certificationNumber, etc., which are used to store the relevant identification and attribute information of CD files. It should be noted that, in this article, component processors refer to classes that implement specific interfaces (such as ComponentHandler, etc.), such as StringHandler and FileHandler. Similarly, the verifier, serializer / deserializer, and storage adapter mentioned later all refer to specific strategies in the strategy pattern, which are part of the application and run on the application server's CPU. They are all software implementation-level terms and do not have the same meaning as the "processor" mentioned in the subsequent device embodiments.

[0030] Figure 2 This is a flowchart illustrating a component data processing method supporting multiple types of extensions provided in another embodiment of the present invention, as shown below. Figure 2 As shown, further, in this embodiment of the application, the method further includes: receiving a front-end request for echoing stored component data, and querying and obtaining the corresponding target component data from the database; routing the target component data to the corresponding component processor through a strategy factory according to the component type in the target component data; and calling a deserializer through the component processor to deserialize the target component data into the echo format required by the front-end and returning it to the front-end.

[0031] Corresponding to the above data entry process, when displaying data, in addition to the format of the entered data, necessary fields such as data addition time (addTime) and operator (operator) are added. Simultaneously, the content of type-specific fields in special extended attributes is adjusted for different types of components to ensure that the front-end can directly use the displayed data. For example, in the display format of firmware-type component data, fields such as firmware name (name), start address (startAddress), and availability flag (available) are added to meet the front-end's requirements for displaying firmware information. Furthermore, in this embodiment, based on the component type, the component data is routed to the corresponding component processor according to a preset strategy factory, and the component data is processed and stored in the database by the component processor, including: calling a preset validator through the component processor to verify the component data; if the verification passes, calling a preset serializer through the component processor to serialize the component data into a preset storage format; and inserting the serialized data into the product resource component table of the database through the component processor using a preset storage adapter.

[0032] Specifically, in some embodiments of this application, the verifier, serializer, and storage adapter can be modules independent of the component processor. In practical applications, they are matched with the component processor so that the component processor can process and store the component data. Of course, in other embodiments of this application, the verifier, serializer, and storage adapter can also be directly encapsulated in the component processor (e.g., the corresponding verifier, serializer, and storage adapter are all or partly encapsulated in the component processor based on the component type of the component data), so that the component processor can implement functions including automated verification, standardized serialization (when storing) / deserialization (when echoing).

[0033] For automated validation, specific validation rules can be defined in the corresponding component handler for each component type. For example, string components can validate whether the data is in text format, numeric components can validate whether the data is a valid value, file components can validate whether the file type and size meet the limits, and key / certificate components can validate whether the key / certificate exists. When the server receives the data submitted by the front end, it routes the component data to the corresponding component handler according to the component type. The component handler then calls the validator to automatically execute the validation logic. If the validation fails, error details are returned; if the validation succeeds, the subsequent data processing flow begins. For standardized serialization / deserialization, by defining unified serialization rules, the unified JSON format data submitted by the front end (the component data submitted by the front end based on the basic data structure is in JSON format) is serialized into a format that can be stored in the database. At the same time, deserialization rules for different component types are defined and set, and the data in the database is deserialized into the format required by the front end when echoing, thereby ensuring the consistency and efficiency of data interaction between the front end and the back end.

[0034] In practical applications, a system used to execute component data processing methods that support multiple types of extensions is called a component data processing system that supports multiple types of extensions. It includes a front-end, a server, and a database module, and the components interact with each other via a network.

[0035] Specifically, the front-end is responsible for inputting and displaying component data, constructing component data according to a unified JSON format and submitting it to the server, while also receiving the echo data returned by the server and displaying it on the page.

[0036] The server-side includes components such as the strategy factory, component handlers (e.g., String handler, File handler, Cert handler, Firmware handler), validators, serializers, and storage adapters. Deployed on the application server, the server receives data submitted from the frontend, routes it to the corresponding component handler via the strategy factory, and the component handler calls the validator to perform data validation. If validation passes, the serializer serializes the data into a database format, and the storage adapter stores the data in the database. When receiving an echo request from the frontend, the storage adapter reads data from the database, the handler calls the deserializer to deserialize the data into an echo format, and finally returns it to the frontend. The database module can use an existing relational database (such as MySQL) or a non-relational database (such as MongoDB) to store component data. The database table structure is based on a unified basic data structure design, including basic field columns and extended attribute field columns (extended attribute field columns can be stored in JSON format to support extended attributes of different types of components). Furthermore, in some embodiments of this application, the aforementioned front-end and server-side can be implemented based on a processing mechanism that combines a layered architecture with a strategy pattern. Specifically, for a layered architecture, the system is divided into a front-end data submission layer (i.e., the front end), a server-side data processing layer, a data validation layer, a data storage layer, and a data deserialization layer. Each layer has a single responsibility, achieving separation of concerns and avoiding functional coupling.

[0037] The front-end data submission layer is responsible for submitting component data in a unified format; the data processing layer is responsible for receiving data and performing component type identification and routing; the data validation layer is responsible for executing the corresponding automated validation logic based on the component type; the data storage layer is responsible for storing the validated data into the database in the designed ingestion format; and the data deserialization layer is responsible for deserializing the data in the database into the display format required by the front-end when the front-end requests the display data. For the strategy pattern, the strategy factory and component processor are designed as described above. The strategy factory routes component data to the corresponding component processor according to the component type. Each component processor encapsulates the specific verification rules, data processing logic, and serialization / deserialization logic for that type of component.

[0038] Based on this, the method also includes: receiving a user's request to add a new component type; registering a component processor corresponding to the new component type in the strategy factory, and configuring a corresponding validator, serializer, and storage adapter for the registered component processor.

[0039] In this way, when a new component type is added, only the corresponding component processor needs to be added. There is no need to modify the core logic of the strategy factory and the existing processors, which realizes the open-closed principle of being open to extension and closed to modification. At the same time, by defining a unified method for component processors through an abstract interface, the implementation of low-level modules (such as the data processing layer on the server side) is not dependent on the implementation of low-level modules (such as component processors), thus satisfying the dependency inversion principle. In practical applications, the system provided in this application standardizes the data of all components, i.e., the component data interaction format, through a unified data contract design. This simplifies the front-end and back-end development process, reduces the complexity of system integration, and ensures the consistency of front-end and back-end data interaction. Based on the strategy pattern and the open / closed principle, when adding a new component type, only the corresponding component processor needs to be added, without modifying the core system logic. This enables flexible expansion of component types and meets the needs of subsequent system function expansion. The automated data verification mechanism avoids the repetitive writing and omission of verification logic, improving the accuracy and efficiency of data verification. The standardized serialization / deserialization process reduces the workload of front-end data processing and improves the efficiency of data interaction. The layered architecture design achieves separation of concerns, with clear responsibilities for each layer, reducing functional coupling and facilitating subsequent system maintenance and upgrades. The unified basic data structure and clear component boundaries enable developers to quickly understand and maintain the system code.

[0040] The following section uses actual component data as an example to detail the process of its import and display: The first step is the warehousing process: 1. Front-end users input relevant information about the CD file component (such as the component's unique identifier key, display label, data version, and other basic fields). This information is then used to construct unified JSON data according to the special database entry format of the DACTemplate type. The specific format is as follows: { "key":"Cert_002", "label":"Device Identity Certificate", "version":"3.1.0", "fieldType":"DACTemplate", "name":"Device Identity Certificate_V1.0", "attribute":{ "value":"DAC_ID" }, "extFieldFlag":1, "mandatoryFlag":1, } 2. The front end submits the above JSON data to the server's resource data via an HTTP request.

[0041] 3. After receiving the data, the server parses the component type in the data, namely the fieldType field (with the value "DACTemplate"), through the strategy factory, and routes the data to the DACTemplate processor. 4. The DACTemplate processor calls the validator to execute the validation rules for CD file type components, such as whether the ID (value) is valid. 5. If the verification fails (e.g., the ID does not exist), the verifier returns error details (e.g., "DAC certificate ID123456 does not exist, please select a new certificate"). The server encapsulates the error details into an error response and returns it to the front end, where the error information is displayed. 6. If the verification is successful, the DACTemplate processor calls the serializer to serialize the JSON data into a format that the database can store (such as converting the JSON data of the extended attribute fields into a JSON type or string type supported by the database), and then inserts the serialized data into the product resource component table of the database through the storage adapter. Then comes the echoing process: 1. The front-end user initiates a query request for certificate component data, specifying the unique identifier of the component (such as "Cert_002").

[0042] 2. After receiving the request, the server queries the database based on the unique identifier of the component through the storage adapter, such as querying the product resource component table in the database, to obtain the storage data of the certificate component (including fields such as key, label, version, fieldType, attribute, addTime, operator, env, dataCode, dataType, available, etc.).

[0043] 3. The server parses the fieldType field (with the value "DACTemplate") in the stored data through the policy factory and routes the stored data to the DACTemplate (certificate) processor. 4. The DACTemplate processor calls the deserializer to deserialize the extended attribute field data stored in the database (such as the JSON string of the attribute field) into a format that can be displayed on the front end. At the same time, it adds the necessary fields for echoing (such as addTime, operator, etc.) and generates the echo data of the certificate type component. The specific format is as follows: { "key": "Cert_002", "label": "Device Identity Certificate", "version": "3.1.0", "fieldType": "DACTemplate", "name": "Device Identity Certificate_V1.0", "addTime": "2025-08-25T10:30:00.000+0800", "operator": "user_001", "attribute": { "value": "CertData_789 }, "extFieldFlag": 1, "mandatoryFlag": 1, "env": "test", "dataCode": "Cert UUID_002", "dataType": 1, "available": 1 } 5. The server encapsulates the deserialized echo data into a response and returns it to the front end. The front end parses the response data and displays the relevant information of the certificate component (such as certificate name, addition time, operator, certificate data value, etc.) according to the page design.

[0044] Based on the same inventive concept, this application also provides a component data processing apparatus that supports multiple types of extensions, for implementing the above method embodiments. Figure 3 This is a schematic diagram of the structure of a component data processing system supporting multiple types of extensions provided in an embodiment of the present invention, such as... Figure 3 As shown, the system includes: Frontend 11 is used to generate component data based on the basic data structure representation; Server 12 is used to define modules and basic data structures, including basic fields and extended attribute fields. The basic fields include component type; parsing the component type in the component data; and routing the component data to the corresponding component processor based on the component type and a preset strategy factory, and processing and storing the component data in the database through the component processor. Database 13 is used to store data processed by the component processor.

[0045] Regarding the system in the above embodiments, the specific manner in which each part performs its operations has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0046] The present invention also provides a component data processing system device that supports multiple types of extensions, for implementing the above method embodiments. Figure 4 This is a schematic diagram of the structure of a component data processing device supporting multiple types of extensions provided in an embodiment of the present invention, such as... Figure 4 As shown, the component data processing device supporting multiple types of expansion in this embodiment includes a processor 21 and a memory 22, with the processor 21 connected to the memory 22. The processor 21 is used to call and execute a program stored in the memory 22; the memory 22 is used to store the program, which is at least used to execute the component data processing method supporting multiple types of expansion in the above embodiments.

[0047] The specific implementation scheme of the component data processing device supporting multiple types of expansion provided in this application embodiment can refer to the implementation scheme of the component data processing method supporting multiple types of expansion in any of the above embodiments, and will not be repeated here.

[0048] It is understood that the same or similar parts in the above embodiments can be referred to each other, and the contents not described in detail in some embodiments can be referred to the same or similar contents in other embodiments.

[0049] It should be noted that in the description of this invention, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Furthermore, in the description of this invention, unless otherwise stated, "a plurality of" means at least two.

[0050] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process, and the scope of the preferred embodiments of the invention includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as will be understood by those skilled in the art to which embodiments of the invention pertain.

[0051] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0052] Those skilled in the art will understand that all or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, the program includes one or a combination of the steps of the method embodiments.

[0053] Furthermore, the functional units in the various embodiments of the present invention can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium.

[0054] The storage media mentioned above can be read-only memory, disk, or optical disk, etc.

[0055] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0056] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A component data processing method supporting multiple types of extensions, characterized in that, include: Define a basic data structure, which includes basic fields and extended attribute fields, wherein the basic fields include component types; Receive component data submitted by the front end based on the aforementioned basic data structure; Parse the component type in the component data; Based on the component type, the component data is routed to the corresponding component processor using a preset strategy factory, and the component processor processes and stores the component data.

2. The component data processing method supporting multiple types of extensions according to claim 1, characterized in that, The basic fields include: component unique identifier, display label, data version, component type, extended field flag, required field flag, removed item flag, edit item keyword flag, and edit item type flag; The extended attribute fields include: basic extended attributes and special extended attributes; The basic extended attributes include single data values ​​and array data values, used to identify and store numerical values ​​of string, number, and Boolean data; the special extended attributes include type-specific fields, used to identify and store specific fields of file, certificate, key, and firmware type data.

3. The component data processing method supporting multiple types of extensions according to claim 1, characterized in that, Based on the component type, the component data is routed to the corresponding component processor using a preset strategy factory, and the component processor processes and stores the component data, including: The component processor calls a preset verifier to verify the component data. If the verification passes, the component processor calls a preset serializer to serialize the component data into a preset database format. The component processor uses a preset storage adapter to insert the serialized data into the product resource component table of the database.

4. The component data processing method supporting multiple types of extensions according to claim 3, characterized in that, The verifier, serializer, and storage adapter are encapsulated within their respective component processors.

5. The component data processing method supporting multiple types of extensions according to claim 1, characterized in that, Also includes: Receive the front end's request to display stored component data, and query the database to retrieve the corresponding target component data; Based on the component type in the target component data, the strategy factory routes the target component data to the corresponding component processor; The component processor calls the deserializer to deserialize the target component data into the echo format required by the front end and return it to the front end.

6. The component data processing method supporting multiple types of extensions according to claim 3, characterized in that, Also includes: Receive user requests to add new component types; Register the component processor corresponding to the newly added component type in the policy factory, and configure the corresponding validator, serializer and storage adapter for the registered component processor.

7. The component data processing method supporting multiple types of extensions according to claim 3, characterized in that, The component data submitted by the front end, based on the aforementioned basic data structure, is in JSON format.

8. A component data processing system supporting multiple types of extensions, characterized in that, include: The front end is used to generate component data based on the underlying data structure representation; The server is used to define modules and to define basic data structures, including basic fields and extended attribute fields. The basic fields include component types. The server also parses the component types from the component data. Based on the component type, the component data is routed to the corresponding component processor according to a preset strategy factory, and the component processor processes and stores the component data in the database. A database is used to store the data processed by the component processor.

9. The component data processing system supporting multiple types of extensions according to claim 8, characterized in that, The server is also used to receive the front end's echo request for stored component data, query and obtain the target component data corresponding to the echo request, convert the target component data into the echo format required by the front end, and return it to the front end.

10. A component data processing device supporting multiple types of expansion, characterized in that, It includes a processor and a memory, wherein the processor is connected to the memory: The processor is used to call and execute the program stored in the memory; The memory is used to store the program, which is at least used to execute the component data processing method supporting multiple types of extensions as described in any one of claims 1-7.

Images