Business data processing method of cross-platform application, cross-platform application system, device and program product
By employing a layered architecture and a unified data processing mechanism, the problems caused by the coupling between business logic and the platform in cross-platform applications are resolved, achieving high efficiency, reusability, and stability, and simplifying the development and maintenance process.
Patent Information
- Application Number
- CN202610269257.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-03-05
- Publication Date
- 2026-07-03
AI Technical Summary
In existing technologies, cross-platform application development suffers from low development efficiency, poor system stability and robustness, poor code reusability, and insufficient maintainability and testability due to the tight coupling between business logic and platform implementation.
It adopts a layered architecture, including a user interface layer, an application layer, a domain layer, and an infrastructure layer. Through clear division of responsibilities and dependency management, the core business logic is encapsulated in an independent domain layer, providing a unified warehousing service for data processing, defining platform-independent abstract operation interfaces, and using platform adapters for cross-platform adaptation.
It achieves high-efficiency reusability of cross-platform applications, improves system stability and robustness, simplifies the process of changing business rules and technical frameworks, reduces repetitive development work, and enhances system flexibility and testability.
Smart Images
Figure CN122331868A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of computer software development technology, and in particular relates to a business data processing method, cross-platform application system, device and program product for cross-platform applications. Background Technology
[0002] With the development of mobile internet, developing cross-platform applications that can run on multiple operating systems and devices has become a mainstream requirement. However, in traditional software development practices, there is a common problem of high coupling between core business logic and user interface framework, as well as specific technical implementations (such as database access, network requests, etc.).
[0003] This highly coupled architecture leads to numerous technical drawbacks. First, code reusability is extremely poor. The same set of core business rules, such as the power generation efficiency calculation rules for power plants in an energy system, needs to be repeatedly written and adapted for different target platforms (such as mobile applications, web applications, and mini-programs). This not only significantly increases development costs and time but also makes the codebase bloated and difficult to maintain. Second, data processing logic is chaotic, resulting in low system robustness. Due to the lack of a unified and standardized processing mechanism, operations such as format validation, data cleaning, and missing field filling for data from external data sources are often repeatedly implemented across various modules of the system. This easily leads to runtime errors such as data inconsistencies and null pointer exceptions, seriously affecting the stability and robustness of the system. Furthermore, the system's maintainability and testability are severely inadequate. Because business logic and technical implementation are mixed, the responsibilities of each part of the system are unclear, making subsequent functional iterations and business rule changes extremely difficult and risky. Summary of the Invention
[0004] This application provides a business data processing method, a cross-platform application system, a device, and a program product for cross-platform applications. It can solve the technical problems in the prior art, such as low development efficiency, poor system stability, and poor robustness of cross-platform applications caused by the tight coupling between business logic and platform implementation.
[0005] In a first aspect, embodiments of this application provide a business data processing method for a cross-platform application. The method is applied to a cross-platform application system, which adopts a layered architecture, including a user interface layer, an application layer, a domain layer, and an infrastructure layer.
[0006] The method includes: The user interface layer receives service requests and sends the service requests to the application layer. The application layer invokes the warehousing interface defined in the domain layer according to the business request. The system responds to the call to the warehousing interface through the warehousing service provided in the infrastructure layer to obtain the domain model object and send the domain model object to the application layer. Through the application layer, the domain layer is triggered to execute business logic processing on the domain model object to generate business processing results; The application layer converts the domain model object containing the business processing result into a data transmission object and returns it to the user interface layer for display.
[0007] In one possible implementation of the first aspect, the step of responding to a call to the repository interface via a repository service provided in the infrastructure layer to obtain a domain model object includes: Check the local cache to see if there is cached data that matches the business request; If it exists, then construct the domain model object based on the cached data; If it does not exist, the original business data is obtained from an external data source and the original business data is standardized. The domain model object is constructed based on the standardized business data, and the standardized business data is synchronized to the local cache.
[0008] In one possible implementation of the first aspect, the standardization processing of the original business data includes: The original business data is cleaned using a data adapter to remove invalid or abnormal data. Perform field fallback processing on the cleaned business data, filling in preset default values for missing fields; The business data after field-based fallback is converted to conform to the data type specifications defined in the domain layer.
[0009] In one possible implementation of the first aspect, the method further includes: Define platform-independent abstract operation interfaces in the domain layer or the application layer; In the user interface layer, at least one platform adapter is provided for each target platform; wherein the platform adapter is used to implement the abstract operation interface and convert calls to the abstract operation interface into calls to the native application programming interface of the target platform.
[0010] In one possible implementation of the first aspect, triggering the domain layer to perform business logic processing on the domain model object through the application layer includes: The application layer identifies the business use case corresponding to the business request; Based on the business use case, orchestrate the invocation of one or more domain services, which perform business rule calculations or state change operations on the passed-in domain model object.
[0011] In one possible implementation of the first aspect, the step of triggering the domain layer to perform business logic processing on the domain model object through the application layer to generate a business processing result includes: The application layer calls the domain service in the domain layer and passes the domain model object as an input parameter to the domain service. The domain service performs business calculations or state changes on the domain model object based on its encapsulated business rules to generate the business processing result; or, The application layer calls the business methods defined by the domain model object itself; In response to the call, the domain model object executes its own encapsulated business rules, performs business calculations or changes in state of its own attributes or internal sub-entity sets, and generates the business processing result.
[0012] In one possible implementation of the first aspect, the architecture of the warehousing interface and warehousing service is configured as follows: The warehousing interface is defined in the domain layer and is used to declare data access operations; The warehousing service is provided in the infrastructure layer as an implementation of the warehousing interface. It encapsulates the logic for accessing and retrieving data from the external data source or the local cache, and adapts to different data sources according to the declaration of the warehousing interface. The application layer and the domain layer access data by calling the repository interface defined in the domain layer.
[0013] Secondly, embodiments of this application provide a cross-platform application system for business data processing. The cross-platform application system adopts a layered architecture, which includes a user interface layer, an application layer, a domain layer, and an infrastructure layer. The user interface layer is used to receive business requests and send the business requests to the application layer; The application layer is used to invoke the warehousing interface defined in the domain layer according to the business request; The warehousing service provided in the infrastructure layer responds to the call to the warehousing interface to obtain the domain model object and sends the domain model object to the application layer; The application layer is used to trigger the domain layer to perform business logic processing on the domain model object in order to generate business processing results; In addition, the application layer is used to convert the domain model object containing the business processing result into a data transmission object and return it to the user interface layer for display.
[0014] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the business data processing method for a cross-platform application as described in any of the first aspects above.
[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the business data processing method for a cross-platform application as described in any of the first aspects.
[0016] Fifthly, embodiments of this application provide a computer program product that, when run on a computer device, causes the computer device to execute the business data processing method of the cross-platform application described in any of the first aspects.
[0017] This application's embodiment employs a layered architecture consisting of a user interface layer, application layer, domain layer, and infrastructure layer. Core business logic is completely encapsulated within a platform-independent domain layer, enabling the same business logic code to be highly reusable across different platforms without modification, significantly reducing redundant development work. Furthermore, the clear four-layer architecture ensures that each layer has a single responsibility, separating business logic from technical implementation. When business rules or the technical framework change, only the corresponding layer needs modification, and the layers do not interfere with each other. Secondly, by providing a unified warehousing service in the infrastructure layer to respond to the warehousing interface defined in the domain layer, centralized data acquisition and processing are achieved. All external data enters the system through a single, standardized entry point, avoiding the chaos and inconsistencies caused by fragmented data processing logic.
[0018] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect mentioned above, and will not be repeated here. Attached Figure Description
[0019] To more clearly illustrate the technical solutions in the embodiments of this application, 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0020] Figure 1This is a flowchart illustrating a cross-platform application business data processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the layered architecture of a cross-platform application system provided in an embodiment of this application; Figure 3 This is a schematic diagram of the data processing interaction timing related to a caching strategy provided in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the principle of cross-platform capability adaptation through a platform adapter, provided in one embodiment of this application. Figure 5 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation
[0021] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.
[0022] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.
[0023] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.
[0024] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."
[0025] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0026] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0027] This application provides a business data processing method, a cross-platform application system, and related equipment for cross-platform applications. The method and system aim to solve the technical problems in the prior art, such as low development efficiency, poor system stability, and poor robustness of cross-platform applications caused by the tight coupling between business logic and platform implementation.
[0028] In a specific application scenario, such as querying details of an energy power plant, the business data processing method described in this application is fully demonstrated. This method, in a scenario such as... Figure 2 The illustration shows an implementation of a cross-platform application system employing a layered architecture. This layered architecture divides system responsibilities into a user interface layer 10, an application layer 20, a domain layer 30, and an infrastructure layer 40. This layered architecture, through clear division of responsibilities and dependency management, ensures the independence and reusability of core business logic, providing a foundation for building robust, maintainable, and cross-platform application systems.
[0029] Reference Figure 1 and Figure 3 The complete process of this business data processing method and the detailed signaling interaction process between each layer of components can be clearly displayed.
[0030] S101 receives the service request through the user interface layer 10 and sends the service request to the application layer 20.
[0031] In this embodiment, the user interface layer 10 receives a service request from the user and dispatches the request to the application layer 20 for processing.
[0032] Among them, a business request refers to an operation instruction initiated by a user or external system to trigger a specific business function. It usually contains the data required to execute the function, such as identifiers and parameters.
[0033] In this scenario, when a user clicks the "View Station Details" button in a cross-platform application (such as a Flutter application), the system receives a business request carrying the station ID. This request is then sent to the application service 21 (such as an EnergyStationApplicationService) in the application layer 20, which encapsulates a specific business use case flow, for further processing.
[0034] S102, through the application layer 20, calls the warehousing interface 31 defined in the domain layer 30 according to the business request.
[0035] In this context, repository interface 31 refers to a set of abstract operations defined in domain layer 30. It declares the method signatures for persistent access to domain model objects (such as creation, search, update, and deletion), but does not contain concrete implementations. It constitutes the contract between domain layer 30 and data storage technology.
[0036] Specifically, application service 21 calls the findById method defined in the EnergyStationRepository interface 31 based on the received power station ID, intending to obtain the corresponding power station data. This setup, where application layer 20 and domain layer 30 access data by calling the repository interface 31 defined in domain layer 30, while isolating the specific implementation details of data access in infrastructure layer 40, reflects a clear dependency inversion principle.
[0037] S103, through the storage service 41 provided in the infrastructure layer 40, responds to the call of the storage interface 31 to obtain the domain model object and sends the domain model object to the application layer 20.
[0038] In this context, repository service 41 refers to the specific implementation of the repository interface 31 in the domain layer within the infrastructure layer 40. It encapsulates all the technical details of interacting with specific data sources (such as network APIs, local caches, and databases) and is responsible for performing the actual data read and write operations. It's important to note that repository service 41 can adapt to different data sources based on the declaration of repository interface 31. Specifically, for the same repository interface 31, the infrastructure layer 40 can provide multiple different repository service implementations, such as implementations based on local databases, remote APIs, or memory caches. When the system needs to switch data sources or perform unit tests, it only needs to replace the corresponding repository service implementation through dependency injection, without requiring any modifications to the code in the domain layer 30 and application layer 20. This mechanism provides the system with high flexibility and testability, while also facilitating the dynamic selection of the optimal data access strategy based on the deployment environment.
[0039] A domain model object refers to a software object that encapsulates business data and the business logic (i.e., business methods) that process that data. It reflects the core concepts and behavioral rules of the business domain. For example, an EnergyStation aggregate root is an instance of a domain model object. It not only contains data attributes such as power station capacity (EnergyCapacity value object) and device list (Device entity), but also its own defined business methods such as calculateTotalPower() and addDevice().
[0040] Optionally, S103 responds to the call to the warehouse interface 31 through the warehouse service 41 provided in the infrastructure layer 40 to obtain the domain model object, including: checking whether there is cached data matching the business request in the local cache; if it exists, constructing the domain model object based on the cached data; if it does not exist, obtaining the original business data from the external data source and standardizing the original business data; constructing the domain model object based on the standardized business data, and synchronizing the standardized business data to the local cache.
[0041] In this embodiment of the application, the process of the warehousing service 41 obtaining the domain model object includes a caching strategy, as shown in the appendix. Figure 3 As shown in the sequence diagram, repository service 41 first accesses the local cache (e.g., a LocalEnergyStationRepository) to check if cached data matches the requested station ID. If the cache is hit, the repository service directly constructs an EnergyStation domain model object based on the cached data and returns it to the application layer 20 (i.e., when the cache is hit, the repository service directly obtains the cached data from the local cache, constructs a domain model object based on the cached data, and then returns the domain model object to the application layer without accessing an external data source). If the cache is not hit, repository service 41 accesses an external data source (e.g., a backend API server) through the network module to obtain the original business data (e.g., data in JSON format).
[0042] The acquired raw business data is not directly used to construct domain model objects. Instead, it is first sent to data adapter 42 for unified data standardization processing. Data standardization processing refers to a unified, pre-defined normalization process for the raw business data to ensure that the data entering the domain layer 30 is clean, complete, and correctly formatted. This process specifically includes: cleaning the raw business data through the data adapter to remove invalid or abnormal data (such as null values or incorrectly formatted entries); then performing field fallback processing on the cleaned business data, filling missing fields (such as stationName) with pre-defined default values (such as unknown power station) to ensure the integrity of the data objects; finally, performing type conversion on the field-fallback-processed business data, converting the data fields to the standard data types required by the domain model (such as converting date strings to DateTime objects), ultimately generating standardized business data that conforms to the data type specifications defined in the domain layer.
[0043] The standardized clean business data is used to construct the EnergyStation domain model object and is also synchronized to the local cache for rapid response to subsequent identical requests. Finally, the constructed EnergyStation domain model object is sent to the application layer 20.
[0044] S104 After receiving the domain model object, the application layer 20 triggers the domain layer 30 to perform business logic processing on the domain model object in order to generate business processing results.
[0045] In this embodiment of the application, the process of performing business logic processing on domain model objects can support two methods.
[0046] The first approach involves the application layer identifying the business use case corresponding to the business request. Based on the business use case, it orchestrates calls to one or more domain services. The domain services then perform business rule calculations or state change operations on the passed-in domain model object. Alternatively, the application layer calls the domain service in the domain layer, passing the domain model object as an input parameter. The domain service then performs business calculations or state changes on the domain model object based on its encapsulated business rules to generate the business processing result.
[0047] In this embodiment, when the business logic is complex and spans multiple domain objects, the application layer 20 identifies the business use case corresponding to the business request and orchestrates the invocation of one or more domain services 32 defined in the domain layer 30 based on the use case. Here, a domain service 32 refers to a stateless service that encapsulates important business operations that are not suitable for placement in any single entity or value object. For example, the application layer 20 invokes EnergyCalculationService (a domain service 32) and passes the EnergyStation domain model object as an input parameter, allowing this service to perform complex power generation efficiency calculations.
[0048] The second approach involves the application layer calling the business methods defined by the domain model object itself. In response to the call, the domain model object executes its own encapsulated business rules, performs business calculations or changes to its own attributes or internal sub-entity sets, and generates business processing results.
[0049] In this embodiment, for business operations that fall under the responsibilities of the domain model object itself, the application layer 20 can directly call the business methods defined by the domain model object itself. For example, it can directly call the energyStation.checkStatus() method, which allows the object to execute its own encapsulated business rules and perform business calculations or state changes on its own attributes or internal sub-entity collections. For example, calling the calculateTotalPower() method of the EnergyStation aggregate root is an example of this approach.
[0050] S105, through the application layer 20, the domain model object containing the business processing result is converted into a data transfer object (DTO) and returned to the user interface layer 10 for display by the user interface layer.
[0051] In this context, a data transfer object refers to an object that serves solely as a pure data container, with the sole purpose of transferring data between different layers or processes, and does not contain any business logic.
[0052] In this scenario, application layer 20 converts the updated EnergyStation domain model object into an EnergyStationDTO. This DTO retains only the data that needs to be displayed on the interface (such as the power station name and power generation efficiency) and removes all business methods. Finally, the EnergyStationDTO is returned to user interface layer 10 for rendering and display, thus completing the entire business data processing flow.
[0053] In an optional embodiment, to decouple core business logic from platform-related capabilities, this application also provides a cross-platform adaptation mechanism. Specifically, at the domain layer or application layer, a platform-independent abstract operation interface is defined; at the user interface layer, at least one platform adapter is provided for each target platform; wherein, the platform adapter is used to implement the abstract operation interface and convert calls to the abstract operation interface into calls to the target platform's native application programming interface.
[0054] Reference Figure 4 This mechanism can be applied to handle platform capability calls related to device hardware, such as the function of scanning QR codes to register devices. First, in the domain layer 30 or application layer 20, a platform-independent abstract operation interface, such as IScannerAdapter, is defined. This abstract operation interface represents a contract defining a specific function (such as scanning, location, or storage), independent of the specific platform implementation; upper-layer business logic relies solely on this interface for programming. This interface may contain a method such as scanQRCode(). Next, in the user interface layer 10, at least one platform adapter 11 is provided for each target platform. This platform adapter 11 represents a concrete implementation of the aforementioned abstract operation interface, responsible for translating or bridging calls to the abstract interface to the native application programming interface (API) of the specific target platform. For example, for the Flutter platform, a Flutter platform adapter can be provided, whose scanQRCode method internally calls Flutter's native API (e.g., through a QR code scanning plugin); for the Web platform, a Web platform adapter can be provided, whose scanQRCode method internally uses Web native APIs (e.g., the getUserMedia and jsQR libraries). When the upper-layer business logic (e.g., application layer 20) calls the `scanQRCode` method of `IScannerAdapter`, the system automatically provides the corresponding platform adapter (such as the Flutter platform adapter or the Web platform adapter) instance to perform the operation based on the currently running platform. Therefore, the upper-layer business logic code does not need any modification to call its native QR code scanning function on different platforms, thus achieving decoupling between business logic and platform capabilities.
[0055] Furthermore, the layered architecture provided in this application also boasts excellent compatibility and scalability, allowing integration with design patterns such as Command Query Responsibility Separation (CQRS) to address more complex business scenarios. For example, operations in the system can be categorized into two types: commands that change the system state and queries that do not. For write operations (commands), the complete process described in the above embodiments can be strictly followed, ensuring data consistency and business correctness by loading the domain model and executing business rules. For instance, a request to add a new device will create an AddDeviceCommand object through the application layer 20, load the EnergyStation aggregate root by the command processor, execute the addDevice() business method, and then save the changes through the repository service 41. For read operations (queries), optimizations can be made to improve performance. For example, a separate event listener can be set up to update the data in a dedicated read model database for queries after the write operation is completed. When the user interface layer 10 requests to view the list of power plant equipment, a query service in the application layer 20 can quickly retrieve data directly from this model database and construct a DTO to return, thereby bypassing the complex domain model loading and calculation process, improving data query performance and system scalability.
[0056] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0057] Corresponding to the cross-platform application business data processing method described in the above embodiments, this application also provides a cross-platform application system for business data processing. (Refer to...) Figure 2 The system adopts a layered architecture, including a user interface layer 10, an application layer 20, a domain layer 30, and an infrastructure layer 40. The user interface layer 10 is used to receive business requests and send them to the application layer 20.
[0058] User interface layer 10 is used to receive business requests and send them to application layer 20; Application layer 20 is used to call the warehousing interface 31 defined in domain layer 30 according to business requests; The warehousing service 41 provided in the infrastructure layer 40 responds to the call of the warehousing interface 31 to obtain the domain model object and send the domain model object to the application layer 20; Application layer 20 is used to trigger domain layer 30 to perform business logic processing on domain model objects in order to generate business processing results; In addition, the application layer 20 is used to convert the domain model object containing the business processing results into a data transmission object and return it to the user interface layer 10 for display.
[0059] It should be noted that the information interaction and execution process between the above-mentioned components are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.
[0060] This application also provides a computer device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.
[0061] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.
[0062] This application provides a computer program product that, when run on a computer device, enables the computer device to execute the steps described in the various method embodiments above.
[0063] Figure 5 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Figure 5 As shown, the computer device of this embodiment includes: at least one processor 50 ( Figure 5 Only one is shown in the diagram), memory 51, and computer program 52 stored in said memory 51 and executable on said at least one processor 50, wherein said processor 50 executes said computer program 52 to implement the steps in the above embodiments of the business data processing methods for any of the cross-platform applications.
[0064] The computer device may include, but is not limited to, a processor 50 and a memory 51. Those skilled in the art will understand that... Figure 5 The examples of computer devices are merely examples and do not constitute a limitation on computer devices. They may include more or fewer components than shown in the illustration, or combinations of certain components, or different components. For example, they may also include input / output devices, network access devices, etc.
[0065] The processor 50 may be a Central Processing Unit (CPU), or it may be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor.
[0066] In some embodiments, the memory 51 may be an internal storage unit of the computer device, such as a hard disk or memory. In other embodiments, the memory 51 may be an external storage device of the computer device, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc. Furthermore, the memory 51 may include both internal and external storage units of the computer device. The memory 51 is used to store the operating system, applications, bootloader, data, and other programs, such as the program code of the computer program. The memory 51 can also be used to temporarily store data that has been output or will be output.
[0067] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a device / computer equipment, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks.
[0068] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0069] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0070] In the embodiments provided in this application, it should be understood that the disclosed apparatus / computer devices and methods can be implemented in other ways. For example, the apparatus / computer device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings or direct couplings or communication connections may be through some interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.
[0071] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0072] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A business data processing method for cross-platform applications, characterized in that, The method is applied to a cross-platform application system, which adopts a layered architecture, including a user interface layer, an application layer, a domain layer, and an infrastructure layer. The method includes: The user interface layer receives service requests and sends the service requests to the application layer. The application layer invokes the warehousing interface defined in the domain layer according to the business request. The system responds to the call to the warehousing interface through the warehousing service provided in the infrastructure layer to obtain the domain model object and send the domain model object to the application layer. The application layer triggers the domain layer to execute business logic processing on the domain model object to generate business processing results. The application layer converts the domain model object containing the business processing result into a data transmission object and returns it to the user interface layer for display.
2. The method as described in claim 1, characterized in that, The process of responding to calls to the warehousing interface through the warehousing service provided in the infrastructure layer to obtain domain model objects includes: Check the local cache to see if there is cached data that matches the business request; If it exists, then construct the domain model object based on the cached data; If it does not exist, the original business data is obtained from an external data source and the original business data is standardized. The domain model object is constructed based on the standardized business data, and the standardized business data is synchronized to the local cache.
3. The method as described in claim 2, characterized in that, The standardization process for the original business data includes: The original business data is cleaned using a data adapter to remove invalid or abnormal data. Perform field fallback processing on the cleaned business data, filling in preset default values for missing fields; The business data after field-based fallback is converted to conform to the data type specifications defined in the domain layer.
4. The method as described in claim 1, characterized in that, The method further includes: Define platform-independent abstract operation interfaces in the domain layer or the application layer; In the user interface layer, at least one platform adapter is provided for each target platform; wherein the platform adapter is used to implement the abstract operation interface and convert calls to the abstract operation interface into calls to the native application programming interface of the target platform.
5. The method as described in claim 1, characterized in that, The step of triggering the domain layer to execute business logic processing on the domain model object through the application layer includes: The application layer identifies the business use case corresponding to the business request; Based on the business use case, orchestrate the invocation of one or more domain services, which perform business rule calculations or state change operations on the passed-in domain model object.
6. The method as described in claim 1, characterized in that, The step of triggering the domain layer to execute business logic processing on the domain model object through the application layer to generate business processing results includes: The application layer calls the domain service in the domain layer and passes the domain model object as an input parameter to the domain service. The domain service performs business calculations or state changes on the domain model object based on its encapsulated business rules to generate the business processing result; or, The application layer calls the business methods defined by the domain model object itself; In response to the call, the domain model object executes its own encapsulated business rules, performs business calculations or changes in state of its own attributes or internal sub-entity sets, and generates the business processing result.
7. The method as described in claim 1, characterized in that, The architecture of the warehousing interface and warehousing service is set as follows: The warehousing interface is defined in the domain layer and is used to declare data access operations; The warehousing service is provided in the infrastructure layer as an implementation of the warehousing interface. It encapsulates the logic for accessing and retrieving data from the external data source or the local cache, and adapts to different data sources according to the declaration of the warehousing interface. The application layer and the domain layer access data by calling the repository interface defined in the domain layer.
8. A cross-platform application system for business data processing, characterized in that, The cross-platform application system adopts a layered architecture, which includes a user interface layer, an application layer, a domain layer, and an infrastructure layer. The user interface layer is used to receive business requests and send the business requests to the application layer; The application layer is used to invoke the warehousing interface defined in the domain layer according to the business request; The warehousing service provided in the infrastructure layer responds to the call to the warehousing interface to obtain the domain model object and sends the domain model object to the application layer; The application layer is used to trigger the domain layer to perform business logic processing on the domain model object in order to generate business processing results; In addition, the application layer is used to convert the domain model object containing the business processing result into a data transmission object and return it to the user interface layer for display.
9. A computer device, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as claimed in any one of claims 1 to 7.
10. A computer program product, characterized in that, Includes a computer program that, when run, implements the method as described in any one of claims 1 to 7.