CN112905172A

CN112905172A - Component management method and device of application development framework, storage medium and electronic equipment

Info

Publication number: CN112905172A
Application number: CN202110279187.3A
Authority: CN
Inventors: 付平
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd; Shenzhen Huantai Technology Co Ltd
Priority date: 2021-03-16
Filing date: 2021-03-16
Publication date: 2021-06-04

Abstract

The embodiment of the application discloses a component management method, a device, a storage medium and electronic equipment of an application development framework, wherein the application development framework comprises at least two business function modules, each business function module comprises at least two module components, and at least two module components in the business function modules adopt an interface decoupling mode to carry out component communication; each business function module carries out module communication to the outside through the contained interface layer component; the method comprises the following steps: acquiring a service development demand degree aiming at a target service function module in the at least one service function module; determining a target component to be processed in the target service function module based on the service development demand degree; and performing component management on the target component through decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component. By adopting the embodiment of the application, the multiplexing management efficiency of the components can be improved.

Description

Component management method and device of application development framework, storage medium and electronic equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method and an apparatus for managing components of an application development framework, a storage medium, and an electronic device.

Background

With the rapid development of communication technology and internet, application development and maintenance are very important. In the application development process, an application development framework is often constructed based on business development logic to develop modules with different business functions under the framework, common modules of the whole business systematics are abstracted, and business function logic with common and regular functions is managed based on the application development framework, for example, when the modules are designed and maintained based on development business requirements, module codes can be modified or re-edited based on the application development framework, and the modules meeting the development business requirements are re-compiled.

Disclosure of Invention

The embodiment of the application provides a component management method and device of an application development framework, a storage medium and electronic equipment. The technical scheme of the embodiment of the application is as follows:

in a first aspect, an embodiment of the present application provides a component management method for an application development architecture, where the application development architecture includes at least one service function module, the service function module includes at least two module components, and at least two module components in the service function module perform component communication in an interface decoupling manner; each business function module carries out module communication to the outside through the contained interface layer component; the method comprises the following steps:

acquiring a service development demand degree aiming at a target service function module in the at least one service function module;

determining a target component to be processed in the target service function module based on the service development demand degree;

and performing component management on the target component through decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component.

In a second aspect, an embodiment of the present application provides an apparatus for managing components of an application development framework, where the apparatus includes:

the demand determining module is used for acquiring the service development demand degree of a target service function module in the at least one service function module;

the component determination module is used for determining a target component to be processed in the target business function module based on the business development demand degree;

and the component management module is used for carrying out component management on the target component through the decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component.

In a third aspect, embodiments of the present application provide a computer storage medium storing a plurality of instructions adapted to be loaded by a processor and to perform the above-mentioned method steps.

In a fourth aspect, an embodiment of the present application provides an electronic device, which may include: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the above-mentioned method steps.

The beneficial effects brought by the technical scheme provided by some embodiments of the application at least comprise:

in one or more embodiments of the present application, an electronic device obtains a service development requirement degree for a target service function module in at least one service function module based on an application development framework, and determines a target component to be processed in the target service function module according to the service development requirement degree; the target component is subjected to component management through the interface layer component, the target component and a decoupling interface corresponding to the interface layer component, so that the multiplexing of updating, unloading, expanding and the like of a service function module is realized, and a software development end is not required to compile codes again based on service requirements in the whole service development and maintenance process; the maintenance management of a plurality of modules with high commonality or fitting degree can be realized by taking the module assembly as a unit, the same service function logic among different services can be reused by taking the assembly as a reference, and the module assembly management of the service function is realized, such as hot update, hot plug, hot expansion and the like of the service function module in operation; and the subsequent development based on business requirements can realize high expansibility by expanding the module component based on the application development framework, the module component can be upgraded at any time in the subsequent module operation process, the module component is expanded into a new component, the requirement updating of continuous iteration is met, and the normal operation of the module is not influenced in the whole process.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

Fig. 1 is a flowchart illustrating a method for managing components of an application development framework according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of a service function module related to a component management method provided in an embodiment of the present application;

fig. 3 is a schematic view of a scenario of interaction of interface layer components related to a component management method according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a component update scenario involved in a component management method according to an embodiment of the present application;

FIG. 5 is a flowchart illustrating a component management method of another application development framework according to an embodiment of the present application;

fig. 6 is a schematic view of a scenario of module storage in a warehouse, to which the component management method provided in the embodiment of the present application relates;

fig. 7 is a schematic view of a scenario of a component update involved in a component management method according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a component management apparatus of an application development framework according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a component management apparatus of another application development architecture provided in an embodiment of the present application;

FIG. 10 is a schematic structural diagram of a warehouse management module according to an embodiment of the present disclosure;

FIG. 11 is a block diagram of a component management module according to an embodiment of the present disclosure;

fig. 12 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In the description of the present application, it is to be understood that the terms "first," "second," and the like are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. In the description of the present application, it is noted that, unless explicitly stated or limited otherwise, "including" and "having" and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those steps or elements listed, but may alternatively include other steps or elements not listed, or inherent to such process, method, article, or apparatus. The specific meaning of the above terms in the present application can be understood in a specific case by those of ordinary skill in the art. Further, in the description of the present application, "a plurality" means two or more unless otherwise specified. "and/or" describes the association relationship of the associated objects, meaning that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. The character "/" generally indicates that the former and latter associated objects are in an "or" relationship.

The present application will be described in detail with reference to specific examples.

In one embodiment, as shown in fig. 1, a component management method of an application development architecture is proposed, which can be implemented by means of a computer program and can be run on a component management device of the von neumann-based application development architecture. The computer program may be integrated into the application or may run as a separate tool-like application.

The electronic device may be a device having component management functionality of an application development architecture, including but not limited to: a server, a personal computer, a tablet computer, a smart phone, a computing device or other processing device connected to a wireless modem, etc. The terminal devices in different networks may be called different names, for example: user equipment, access terminal, subscriber unit, subscriber station, mobile station, remote terminal, mobile device, user terminal, wireless communication device, user agent or user equipment, cellular telephone, cordless telephone, Personal Digital Assistant (PDA), device in a 5G network or future evolution network, and the like.

Specifically, the component management method of the application development framework includes:

step S101: and acquiring the service development demand degree aiming at the target service function module in the at least one service function module.

In the application, the application development architecture comprises at least one business function module, and the business function module is composed of module components; illustratively, the module assembly includes at least: the system comprises a data model layer component, a logic layer component, an interface layer component and an interface layer component.

In practical application, according to the functional requirements of software services, the service function modules can adopt a module component-oriented development mode during development, so that the related function modules can be designed and developed in a more realistic mode. In the process of function modules, software developers develop each independent software service function module on the basis of an application development framework related to the application according to actual service needs and service function logic during service development.

In practical application, the development and maintenance of an application development architecture is different from the development of a system architecture in the related art in that the software management of the application development architecture can be from fine particles to component dimensions, common modules of the whole system are abstracted in the related art, common and regular business function logic is uniformly processed by the architecture by taking the modules as units, only based on the common modules, the function reuse among a plurality of business function modules is poor, and under the reuse scenes of business function module updating, unloading, expanding and the like, a software developer needs to write codes based on the business development function logic again. The application development framework related by the application development framework uses the components as a reference, when the business function modules are developed based on different types of business function logics, the modules with high commonality or high fitting degree can be maintained and managed by taking the module components as a unit, the same business function logics among different businesses can be reused by taking the components as the reference, and the modular componentization management of the business functions is realized without redeveloping or even rewriting module codes, such as hot update, hot plug, hot extension and the like of the running business function modules.

Illustratively, the business function module is composed of module components, and the module components can be the fitting of at least one or more of the data model layer components, the logic layer components, the interface layer components and the like developed based on the business function development logic. As shown in fig. 2, fig. 2 is a schematic diagram of an architecture of a service function module, where the service function module in fig. 2 at least includes: the data model layer module, the logic layer module logic, the interface layer module view and the interface layer module interface; each module component is relatively independent.

The Data model layer component may serve as a core of the service function module during service development, and the rest of the components (such as the interface layer component view) in the service function module may not be developed based on the Data model layer component but often depend on the Data model layer component in the module application phase. The data model layer component is responsible for communicating with data sources, such as databases, and provides an interface for other components in the modular structure to use. The nature of the communication depends on the type of data source and the way the Model is implemented.

Illustratively, taking the dependency relationship of the data model layer component model/interface layer component view as an example, as shown in fig. 3, fig. 3 is a schematic view of a scene of interface layer component interaction according to the present application,

an interface layer component view for displaying interactions with a user (e.g., various interfaces);

the combination of the Data model layer component model/interface layer component View can realize the classification of Data storage and Data representation, the separation of the Data storage and the Data display makes it possible to display the same Data on several different views, and a new View can also be realized again, without changing the underlying Data structure, the transmission and editing of Data items can be directly customized without changing the module architecture only by calling the base class Delegate of the Data source Data.

The Data Model layer component Model is responsible for communicating with the Data sources Data and provides an interface for other components in the fabric, such as the view component. The nature of the communication depends on the type of Data source Data and the way the Model is implemented.

The interface layer component View obtains a Model index from the data Model layer component Model, the Model index being a reference to the data item. By providing the Model index to the Model, the View can retrieve data from the data source for interface display or user interaction, e.g., a signal from the Model informs the View of changes that have occurred with respect to the data in the data source, a signal from the View provides information about the displayed data items interacting with the user, a signal from the Delegate is used to inform the Model and View of status information about the current editor at the time of editing.

The logic layer component logic represents that the formulation of business rules (such as audio development rules, communication development rules and the like), the realization of business processes and the like are related to business requirements, namely the logic is related to Domain logic corresponding to a business function module, and the logic layer component logic is used as a caller for a data access party; for the representation party corresponding to the interface layer component View, as a callee, the logical processing of data, such as component functions of modifying, acquiring, deleting and the like of data such as data source data, can be realized, and further, the data processing result can be fed back to the interface layer component View to realize a service function corresponding to the service function module, such as an audio function.

The interface layer component interface is used for being responsible for the external communication of the whole service function module, for example, the external communication of module components such as a data model layer component module and the like is realized through the interface layer component interface, so that the internal logic modification of the module components such as the module and the like in the current service function module based on other service function modules can not affect other external components and interface components, the modification can be converged into a target component to be processed, and the component management can realize hot plug, hot update, multiplexing and the like based on the interface layer component interface.

In addition, at least two module components in the service function module adopt an interface decoupling mode to carry out component communication; each business function module carries out module communication to the outside through the contained interface layer assembly, the module assembly is a software unit capable of realizing a certain function, and the specific form of the assembly can be determined according to factors such as software system environment, programming language and the like of an actual application scene without limitation. For example, a component may be a class, object, software package, and the like.

Specifically, the electronic device may obtain a service development requirement degree for a target service function module in the at least one service function module. That is, in the actual application, whether the function of a service function module under a developed application development architecture meets the requirement is measured according to the current service development requirement, the judgment of the specific requirement can be generally comprehensively measured based on the software requirement dimension, the user requirement dimension, the function requirement dimension and other judgment dimensions, wherein each judgment dimension corresponds to a plurality of indexes set based on the actual application, and each judgment dimension can be quantized in a machine-independent judgment or expert-segment judgment manner, wherein the quantization manner can be to determine the grade or the score of the corresponding judgment dimension, then the quantization indexes of each judgment dimension are integrated to fit the quantization indexes of each judgment dimension (for example, the quantization indexes of each judgment dimension can be fitted in a weighting, adding and other mathematical statistics manner), and the service development requirement degree for the current service function module is determined;

the service development requirement degree is used for measuring the requirement degree of the service function module for service development, which is determined according to the dimensions of the user side, the development end, the operation end and the like, and can be understood as quantification of the requirement degree for service development of the service function module, and quantification can be realized by setting levels and setting scores in practical application. For example, the level may be set, where the service development requirement includes three levels, which are a first service requirement, a second service requirement and/or a third service requirement, where the first service requirement is strong, the second service requirement is general, and the third service requirement is no requirement.

Further, after quantifying the service development requirement of at least one service function module operated or to be operated under the service development framework, the service development requirement degree of the service function module can be determined, so that the service development requirement degree of the target service function module expected to be determined can be obtained.

Furthermore, the electronic device may not quantize the service development requirement of at least one service function module operated or to be operated under the service development framework in advance, but quantize the service development requirement of the target service function module after selecting the target service function module from the service function modules, thereby determining the service development requirement degree of the target service function module. It should be noted that, while determining the service development requirement of the target service function module, the requirements of each sub-dimension of the service development requirement of the target service function module can be generally obtained directly, that is, the quantitative result of each judgment dimension of the target service function module, such as each index corresponding to the software requirement dimension, each index of the user requirement dimension, and each index of the function requirement dimension, can be obtained for each judgment dimension.

Step S102: and determining a target component to be processed in the target service function module based on the service development demand degree.

The target component is an operation object for determining component management of the business function module based on the business development demand degree.

Specifically, it can be determined that component management needs to be performed on a current target business function module based on a business development requirement degree, that is, a current business development requirement, which is difficult to meet, in some embodiments, based on a plurality of business function requirement modules under an application development framework of the present application, module development, compiling, generating codes can be performed without re-performing module development based on the business development requirement, instead, the target components needing management at present are determined based on quantization results of sub-dimensions corresponding to the business development requirement degree, such as indexes corresponding to a software requirement dimension, indexes of a user requirement dimension, and indexes of a function requirement dimension, during module management; for example, determining that the UI element corresponding to the interface layer component view in the target service function module does not meet the requirement based on each index of the user requirement dimension, and determining that the target component is the interface layer component view. And for example, determining that the corresponding data model layer module in the target service function module does not meet the requirement based on each index of the function requirement dimension, and determining that the target module is the data model layer module.

Step S103: and performing component management on the target component through decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component.

In a possible implementation manner, after determining a target component to be processed in the target service function module based on the service development requirement degree, if the component management determined based on the service development requirement degree is: when the target component is unloaded, the electronic device may activate component unloading items through the interface layer component to the outside of the service function module, and execute unloading or removing the target component after the component unloading items are activated, wherein in the execution process, component management is specifically performed through decoupling interfaces corresponding to the target component and the interface layer component: the component uninstall transaction is activated. After unloading, fine grains reach component dimensions when the target business function module is developed, and each module component can be independently decoupled and independently work, so that other components of the target business function module are not affected and do not need to be recompiled.

In a possible implementation manner, after determining a target component to be processed in the target service function module based on the service development requirement degree, if the component management determined based on the service development requirement degree is: determining a reference component for the target component, as shown in fig. 4, where fig. 4 is a schematic diagram of a component update scenario related to the present application, the reference component may be a view1, a logic1, and an interface1, and the target component may be a view, a logic, and an interface;

the reference component is used for replacing the target component and can be selected in a machine determination or expert determination mode; at this time, the electronic device may activate the component update event through the external interface layer component of the service function module, execute updating the target component after the component update event is activated, and specifically perform component management through the target component and the decoupling interface corresponding to the interface layer component during the execution process: the activation component updates the transaction. In the updating process, fine particles reach component dimensions when a target business function module is developed, and each module component can be independently decoupled and independently work, other components of the target business function module are not affected by updating at the moment and do not need to be recompiled, generally, reference components of different businesses can be thermally updated to the target business function module in a JAR (Java object model) package mode through decoupling interfaces corresponding to the target component and the interface layer component, and the whole process module can normally operate and is not affected by component updating.

In the embodiment of the application, the electronic device acquires a service development demand degree for a target service function module in the at least one service function module based on an application development framework, and determines a target component to be processed in the target service function module according to the service development demand degree; the target component is subjected to component management through the interface layer component, the target component and a decoupling interface corresponding to the interface layer component, so that the multiplexing of updating, unloading, expanding and the like of a service function module is realized, and a software development end is not required to compile codes again based on service requirements in the whole service development and maintenance process; the maintenance management of a plurality of modules with high commonality or fitting degree can be realized by taking the module assembly as a unit, the same service function logic among different services can be reused by taking the assembly as a reference, and the module assembly management of the service function is realized, such as hot update, hot plug, hot expansion and the like of the service function module in operation; and the subsequent development based on business requirements can realize high expansibility by expanding the module component based on the application development framework, the module component can be upgraded at any time in the subsequent module operation process, the module component is expanded into a new component, the requirement updating of continuous iteration is met, and the normal operation of the module is not influenced in the whole process.

Referring to fig. 5, fig. 5 is a flowchart illustrating a component management method of an application development framework according to another embodiment of the present application. Specifically, the method comprises the following steps:

step S201: and determining at least two target function modules belonging to the same function logic type in each service function module according to the corresponding function logic type when each service function module is developed.

According to some embodiments, according to the functional requirements of the software service, the service function module can adopt a module component-oriented development mode during development, so as to design and develop a related function module in a more realistic mode. In the development process of the function module, a software developer develops each independent software service function module for an application development framework related by the application according to actual service needs and service function logic during service development, each service function module developed based on the service development logic has independent functions, module components belonging to the same function logic type in each service function module adopt mutually compatible component development specifications during module development, and therefore, when a certain target service function module is designed to be component management, multiplexing among components with different services but the same function logic type can be realized, and components do not need to be re-developed aiming at the target service function module.

The functional logic type is a service functional logic type which is divided according to a service logic development scene and is used for distinguishing different components, the service logic can be understood as different service items which are usually corresponding to different functions, the different functions are realized based on different component architectures, and codes for realizing the core functions are called as service logic. In practical application, a functional logic type corresponding to the current development service can be determined based on different development services, and a service functional module is developed according to a component service specification corresponding to the functional logic type; the functional logic type is one of multiple functional logic types which divide different services based on actual application scenes, and schematically can be divided according to service purposes, and different types of service purposes correspond to different functional logic types, for example, a service functional module for service development based on financial service purposes belongs to a financial functional logic type, and can also be an instant messaging type, an audio playing type and the like;

in the actual functional logic type division, the division can be performed based on media such as a functional requirement table and a functional requirement flow chart which are constructed during service development, and the service functional logics with the same service logic characteristics are divided into the same functional logic type.

Specifically, after the service function modules of different service function logics are developed, at least two target function modules belonging to the same function logic type can be managed based on the corresponding function logic type of each service function module in the development process when the service is developed.

Step S202: and storing the at least two target function modules into a warehouse corresponding to the function logic type.

The warehouse is used for performing unified maintenance management on different target function modules belonging to the same function logic type, the warehouse is substantially used as a storage medium to realize storage of the same type of target function modules and subsequent component maintenance on the operated target function modules, such as component updating, component plugging and the like, the warehouse can be an independent storage space at the local end of the electronic equipment, can be a storage cluster based on a distributed storage architecture, and the like, such as a server cluster. Furthermore, the warehouse can store a plurality of target function modules with different function logic types, and the target function modules with the same type can be marked for storage or can be intensively stored. At least one target function module of the same type in the warehouse can be managed subsequently based on business development requirements. In a possible implementation, a repository may store only target function modules corresponding to one function logic type.

Step S203: and carrying out module management on the target function module in the warehouse.

According to some embodiments, module management is performed on the target function module in the warehouse, and mainly focuses on maintenance management of module components in daily operated or online business function modules, the application development framework is based on components, modules with high commonality or high fitness can be maintained and managed by taking the module components as units, and the same business function logic between different businesses can be reused by taking the components as references, for example, for a certain business function module, when components in the module need to be updated based on business development requirements, components belonging to the same component function logic can be selected from the warehouse to be directly updated and replaced.

Furthermore, the target function modules with the same function logic type stored in the warehouse belong to different service types, and are often stored in the form of jar packages, because the function logic types are the same in the service development stage, therefore, the warehouse daily maintenance order maintains the component development specification of the module component corresponding to the set of functional logic types, as shown in fig. 6, fig. 6 is a schematic view of a scenario of module storage in a warehouse according to the present application, where after development of different development services, such as service 1, service 2, and service 3, is completed, a service function module is formed, target function modules of the same functional logic type stored in the warehouse are respectively belonging to different service types and are often stored in the form of jar packages, daily module maintenance is often performed on the basis of components, and updating and maintaining each module component according to the component development specification of the module component corresponding to the corresponding functional logic type.

In a specific implementation scenario, in the step of storing the warehouse by the electronic device, a reference module component of each target function module in the warehouse may be acquired, and a component function logic corresponding to each reference module component is determined;

the electronic device may specifically determine, based on the component functional logic corresponding to each of the reference module components, at least one target module component belonging to the same component functional logic type; namely, the component function logic type of the module component contained in each target function module stored in the warehouse is determined, and the reference module components belonging to the same component function logic type and belonging to different business function modules are managed in a unified way, wherein the unified management mode includes but is not limited to unified marking, centralized management, component index establishment and the like.

The electronic device can subsequently perform component maintenance management on each target module component.

It can be understood that, when the component development specification of a certain type of module component (e.g. model, logic) is updated, such as incremental update, iterative update, etc., then performing component maintenance management in the repository may specifically be to update target module components belonging to different business function modules, which may belong to the same component functional logic type, according to the component development specification, without redeveloping or even rewriting module component code.

Step S204: and acquiring the service development demand degree aiming at the target service function module in the at least one service function module.

See steps S101-S103 for details, which are not described herein.

Step S205: and determining a target component to be processed in the target service function module based on the service development demand degree.

See steps S101-S103 for details, which are not described herein.

Step S206: determining a target component logic type of the target component, and determining a target warehouse corresponding to the target component logic type;

component updates in component management are defined below that enable easy replacement of components based on module components in the target repository.

In the application, if the target component in the demand target business function module is determined to be replaced based on the business development demand, component maintenance can be performed by adopting a warehouse, the component maintenance is based on two dimensions, the functional logic type corresponding to the business function module and the component logic type corresponding to the target component during the development of the business function module are determined, and the commonly matched target warehouse is determined based on the 'functional logic type of the module' and the 'component logic type'. In some embodiments, the component logic type is divided and is usually mapped to the dimension of "functional logic type of module", so that the target warehouse can be determined directly based on the "component logic type". It will be appreciated that different "component logic types" typically correspond to different repositories.

Step S207: in the target warehouse, a reference component matching the target component is acquired.

In a specific implementation scenario, the electronic device determines a target component function logic corresponding to the target component; then, in the target warehouse, at least one first reference component belonging to the same target component functional logic as the target component may be acquired first; in specific implementation, an inventory index from fine particles to module component dimensions can be pre-established in a warehouse, a plurality of matched components, namely first reference components, can be searched out only by inputting 'target component function logic' to be searched based on the inventory index in application, and one reference component meeting business development requirements can be further selected based on business development requirements because each first reference component belongs to different business types. The selection rule may be determined based on an actual application environment, and different application environments correspond to different selection rules, which are not described herein again.

Step S208: and acquiring interface development parameters corresponding to the target component function logic of the target component, and developing a reference component according to the current business development requirement degree by taking the interface development parameters as a reference.

The interface development parameters may be understood as software interfaces that iterate over versions of the interface application method according to component development specifications.

In a feasible implementation manner, the electronic device may obtain an interface development parameter corresponding to the target component functional logic of the target component, and obtain an updated reference component by updating the interface development parameter of the target component. In a specific embodiment, a transaction update mode can be adopted, and for a component update initiator, the distributed transaction update is performed by calling interface development parameters. The component update initiating end generally corresponds to an update comprising one to a plurality of branch transaction components, and each branch transaction component can correspond to one to a plurality of functional demand points to realize the calling of corresponding interface development parameters. The branch transaction needs to be matched with a calling interface development parameter corresponding to an update initiating terminal, so that a one-stage service provided by the update initiating terminal can be adapted and applied by normally using a component development specification without changing a component architecture, namely, a series of distributed transactions developed based on a service development demand degree are updated to a reference component, and in the updating process, when the electronic equipment serving as the update initiating terminal starts updating, the component is updated by loading and adopting data (such as scripts) of each included branch transaction through the interface development parameter. Further, the branch transaction generally relates to function multiplexing, call development specifications, component application scenarios, SDK specifications, and the like in the current service requirement, and is determined specifically based on an actual application situation and is not specifically developed here.

For example, if the module component view of the service function module corresponding to a certain service, the interface requirement and the interface layer component view are not matched and need to be customized and changed based on the actual situation, multiple branch transactions for service interface update can be developed based on the same set of interface development parameters, each score transaction is loaded and activated by calling the interface development parameters, and the development of custom layer component custom _ view is completed, namely the reference component, so that the custom interface update is realized, the whole process usually does not need to redetermine the component architecture, the compilation of component codes with large versions is not needed, and the rapid hot update of the component can be realized.

Further, based on the update process of the reference component on the target component, at this time, the electronic device may activate a component update item through the interface layer component of the service function module to the outside, and update the target component after the component update item is activated, as shown in fig. 7 in the execution process, fig. 7 is a scene schematic diagram of component update related to the present application, and specifically, in component management, the target component (e.g., component view) and the decoupling interface corresponding to the interface layer component: the activation component updates the transaction. In the updating process, fine particles reach component dimensions when the target service function module is developed, and each module component can be independently decoupled and independently work, other components of the target service function module are not affected by updating at the moment and do not need to be recompiled, generally, reference components of different services are in a JAR (java archive) package form, and can be updated into the target service function module in a hot mode through decoupling interfaces corresponding to the target component and the interface layer component, so that the reference components, such as the customized layer component custom _ view, can be normally operated and are not affected by component updating.

Step S209: based on the decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component, adopting the target component to update the reference component;

specifically, refer to step S103, which is not described herein again.

The following are embodiments of the apparatus of the present application that may be used to perform embodiments of the method of the present application. For details which are not disclosed in the embodiments of the apparatus of the present application, reference is made to the embodiments of the method of the present application.

Referring to fig. 8, a schematic structural diagram of a component management apparatus of an application development framework according to an exemplary embodiment of the present application is shown. The application development framework comprises at least one service function module, the service function module comprises at least two module components, and at least two module components in the service function module adopt an interface decoupling mode to carry out component communication; each business function module carries out module communication to the outside through the contained interface layer component; the component management apparatus of the application development architecture may be implemented as all or a part of an apparatus by software, hardware, or a combination of both. The apparatus 1 comprises a requirement determination module 11, a component determination module 12 and a component management module 13.

A requirement determining module 11, configured to obtain a service development requirement degree for a target service function module in the at least one service function module;

the component determination module 12 is configured to determine a target component to be processed in the target service function module based on the service development requirement degree;

and the component management module 13 is configured to perform component management on the target component through the interface layer component, the target component, and a decoupling interface corresponding to the interface layer component.

Optionally, as shown in fig. 9, the apparatus 1 further includes:

the warehouse management module 14 is configured to determine, in each service function module, at least two target function modules belonging to the same function logic type according to a corresponding function logic type when each service function module is developed;

the warehouse management module 14 is further configured to store the at least two target function modules in a warehouse corresponding to the function logic type, and perform module management on the target function modules in the warehouse.

Optionally, as shown in fig. 10, the warehouse management module 14 includes:

a logic determination unit 141, configured to obtain a reference module component of each target function module in the warehouse, and determine a component function logic corresponding to each reference module component;

a component classifying unit 142, configured to determine, based on the component function logic corresponding to each of the reference module components, at least one target module component belonging to the same component function logic type;

and a component maintenance unit 143 configured to perform component maintenance management on each target module component.

Optionally, the component management module 13 is specifically configured to:

determining a reference component for the target component, and performing component updating processing on the reference component by adopting the target component based on the decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component; and the number of the first and second groups,

and carrying out component unloading processing on the target component based on the decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component.

Optionally, as shown in fig. 11, the component management module 13 includes:

a repository determining unit 131, configured to determine a target component logic type of the target component, and determine a target repository corresponding to the target component logic type;

a component management unit 132, configured to obtain, in the target repository, a reference component matching the target component.

Optionally, the component management unit 132 is specifically configured to:

determining a target component function logic corresponding to the target component;

and acquiring a reference component belonging to the same target component function logic as the target component in the target warehouse.

Optionally, the component management module 13 is specifically configured to:

acquiring interface development parameters corresponding to the target component function logic of the target component, and developing a reference component according to the current business development requirement degree by taking the interface development parameters as a reference; or the like, or, alternatively,

and acquiring interface development parameters corresponding to the target component functional logic of the target component, and updating the interface development parameters of the target component to obtain an updated reference component.

Optionally, the module assembly includes: the system comprises a data model layer component, a logic layer component, an interface layer component and an interface layer component.

It should be noted that, when the component management apparatus of the application development architecture provided in the foregoing embodiment executes the component management method of the application development architecture, only the division of the business function modules is illustrated, and in practical applications, the function distribution may be completed by different business function modules according to needs, that is, the internal structure of the device may be divided into different business function modules to complete all or part of the functions described above. In addition, the component management apparatus of the application development architecture and the component management method embodiment of the application development architecture provided in the above embodiments belong to the same concept, and details of implementation processes thereof are referred to in the method embodiments and are not described herein again.

The above-mentioned serial numbers of the embodiments of the present application are merely for description and do not represent the merits of the embodiments.

An embodiment of the present application further provides a computer storage medium, where the computer storage medium may store a plurality of instructions, and the instructions are suitable for being loaded by a processor and executing the component management method of the application development architecture according to the embodiment shown in fig. 1 to 7, and a specific execution process may refer to specific descriptions of the embodiment shown in fig. 1 to 7, which is not described herein again.

The present application further provides a computer program product, where at least one instruction is stored in the computer program product, and the at least one instruction is loaded by the processor and executes the component management method of the application development architecture according to the embodiment shown in fig. 1 to fig. 7, where a specific execution process may refer to specific descriptions of the embodiment shown in fig. 1 to fig. 7, and is not described herein again.

Referring to fig. 12, a schematic structural diagram of another electronic device is provided in the embodiment of the present application. As shown in fig. 11, the electronic device 2000 may include: at least one processor 2001, at least one network interface 2004, a user interface 2003, memory 2005, at least one communication bus 2002.

The communication bus 2002 is used to implement connection communication between these components.

The user interface 2003 may include a Display screen (Display), and the optional user interface 2003 may also include a standard wired interface or a wireless interface.

The network interface 2004 may optionally include a standard wired interface, a wireless interface (e.g., WI-FI interface), among others.

Processor 2001 may include one or more processing cores, among other things. The processor 2001 connects the various parts within the overall server 2000 using various interfaces and lines, and performs various functions of the server 2000 and processes data by executing or executing instructions, programs, code sets, or instruction sets stored in the memory 2005 and calling data stored in the memory 2005. Optionally, the processor 2001 may be implemented in hardware using at least one of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The processor 2001 may integrate one or a combination of a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a modem, and the like. Wherein, the CPU mainly processes an operating system, a user interface, an application program and the like; the GPU is used for rendering and drawing the content required to be displayed by the display screen; the modem is used to handle wireless communications. It is understood that the modem may not be integrated into the processor 2001, but may be implemented by a single chip.

The Memory 2005 may include a Random Access Memory (RAM) or a Read-Only Memory (Read-Only Memory). Optionally, the memory 2005 includes a non-transitory computer-readable medium. The memory 2005 may be used to store instructions, programs, code, sets of codes, or sets of instructions. The memory 1005 may include a stored program area and a stored data area, wherein the stored program area may store instructions for implementing an operating system, instructions for at least one function (such as a touch function, a sound playing function, an image playing function, etc.), instructions for implementing the various method embodiments described above, and the like; the storage data area may store data and the like referred to in the above respective method embodiments. The memory 2005 may optionally also be at least one memory device located remotely from the aforementioned processor 2001. As shown in fig. 12, the memory 2005, which is a kind of computer storage medium, may include therein an operating system, a network communication module, a user interface module, and a component management application of an application development architecture.

In the electronic device 2000 shown in fig. 12, the user interface 2003 is mainly used as an interface for providing input for a user, and acquiring data input by the user; the processor 2001 may be configured to invoke a component management application program of an application development architecture stored in the memory 2005, where the application development architecture includes at least one service function module, the service function module includes at least two module components, and at least two module components in the service function module perform component communication in an interface decoupling manner; each business function module carries out module communication to the outside through the contained interface layer assembly and specifically executes the following operations:

In one embodiment, before the processor 2001 performs the acquiring the service development requirement degree for the target service function module in the at least one service function module, the following steps are further performed:

determining at least two target function modules belonging to the same function logic type in each service function module according to the corresponding function logic type when each service function module is developed;

and storing the at least two target function modules into a warehouse corresponding to the function logic type, and performing module management on the target function modules in the warehouse.

In one embodiment, the processor 2001 specifically performs the following steps when performing the module management on the target function module in the repository:

acquiring a reference module component of each target function module in the warehouse, and determining a component function logic corresponding to each reference module component;

determining at least one target module component belonging to the same component functional logic type based on the component functional logic corresponding to each reference module component;

and carrying out component maintenance management on each target module component.

In one embodiment, when the processor 2001 executes the component management on the target component through the decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component, the following steps are specifically executed:

determining a reference component for the target component, and performing component updating processing on the reference component by adopting the target component based on the decoupling interfaces corresponding to the interface layer component, the target component and the interface layer component;

or the like, or, alternatively,

In one embodiment, the processor 2001, when performing the determining the reference component for the target component, specifically performs the following steps:

determining a target component logic type of the target component, and determining a target warehouse corresponding to the target component logic type;

in the target warehouse, a reference component matching the target component is acquired.

In one embodiment, the processor 2001 specifically performs the following steps when executing the step of obtaining the reference component matching the target component in the target warehouse:

In one embodiment, the module assembly comprises: the system comprises a data model layer component, a logic layer component, an interface layer component and an interface layer component.

It is clear to a person skilled in the art that the solution of the present application can be implemented by means of software and/or hardware. The "unit" and "module" in this specification refer to software and/or hardware that can perform a specific function independently or in cooperation with other components, where the hardware may be, for example, a Field-ProgrammaBLE Gate Array (FPGA), an Integrated Circuit (IC), or the like.

It should be noted that, for simplicity of description, the above-mentioned method embodiments are described as a series of acts or combination of acts, but those skilled in the art will recognize that the present application is not limited by the order of acts described, as some steps may occur in other orders or concurrently depending on the application. Further, those skilled in the art should also appreciate that the embodiments described in the specification are preferred embodiments and that the acts and modules referred to are not necessarily required in this application.

In the foregoing embodiments, the descriptions of the respective embodiments have respective emphasis, and for parts that are not described in detail in a certain embodiment, reference may be made to related descriptions of other embodiments.

In the embodiments provided in the present application, it should be understood that the disclosed apparatus may be implemented in other manners. For example, the above-described embodiments of the apparatus are merely illustrative, and for example, the division of the units is only one type of division of logical functions, and there may be other divisions when actually implementing, for example, a plurality of units or components may be combined or may be integrated into another system, or some features may be omitted, or not implemented. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection of some service interfaces, devices or units, and may be an electrical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.

The integrated unit, if implemented in the form of a software functional unit and sold or used as a stand-alone product, may be stored in a computer readable memory. Based on such understanding, the technical solution of the present application may be substantially implemented or a part of or all or part of the technical solution contributing to the prior art may be embodied in the form of a software product stored in a memory, and including several instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned memory comprises: various media capable of storing program codes, such as a usb disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a removable hard disk, a magnetic disk, or an optical disk.

Those skilled in the art will appreciate that all or part of the steps in the methods of the above embodiments may be implemented by a program, which is stored in a computer-readable memory, and the memory may include: flash disks, Read-Only memories (ROMs), Random Access Memories (RAMs), magnetic or optical disks, and the like.

The above description is only an exemplary embodiment of the present disclosure, and the scope of the present disclosure should not be limited thereby. That is, all equivalent changes and modifications made in accordance with the teachings of the present disclosure are intended to be included within the scope of the present disclosure. Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. The component management method of the application development architecture is characterized in that the application development architecture comprises at least one business function module, the business function module comprises at least two module components, and at least two module components in the business function module adopt an interface decoupling mode to carry out component communication; each business function module carries out module communication to the outside through the contained interface layer component;

the method comprises the following steps:

2. The method according to claim 1, wherein before the obtaining the service development desirability for the target service function module of the at least one service function module, the method further comprises:

3. The method of claim 2, wherein said module managing said target function modules in said repository comprises:

4. The method of claim 1, wherein the component managing the target component through the decoupling interfaces corresponding to the interface layer component, the target component, and the interface layer component comprises:

or the like, or, alternatively,

5. The method of claim 4, wherein determining the reference component for the target component comprises:

6. The method of claim 5, wherein said obtaining, in the target repository, a reference component that matches the target component comprises:

7. The method of claim 4, wherein determining the reference component for the target component comprises:

8. The method of any of claims 1-7, wherein the modular assembly comprises: the system comprises a data model layer component, a logic layer component, an interface layer component and an interface layer component.

9. A computer storage medium, characterized in that it stores a plurality of instructions adapted to be loaded by a processor and to carry out the method steps according to any one of claims 1 to 8.

10. An electronic device, comprising: a processor and a memory; wherein the memory stores a computer program adapted to be loaded by the processor and to perform the method steps of any of claims 1 to 8.