Program module processing method and device

Abstract

The present application discloses a method and device for processing a program module, the method comprising: loading an entry file of at least one target program module, the target program module including at least one program sub-module, a data definition file, an interface definition file and a configuration information file; the target program module can be loaded separately; according to the interface directory information corresponding to the interface definition file, an interface tree and a module permission tree are generated, the interface tree and the module permission tree are used to process the target program module; the interface directory information represents the functional logical relationship of the program sub-module in the target program module; the module identifiers corresponding to the program sub-modules contained in the interface tree are in a target directory structure, the module identifiers in the interface tree correspond to the interface definition files corresponding to the program sub-modules to which they belong, and the target directory structure matches the interface directory information; and the module identifiers of the program sub-modules contained in the module permission tree are in a target directory structure.

Description

Technical Field

[0001] The present application relates to the field of software development technology, and in particular to a method and device for processing a program module. Background Art

[0002] Currently, software development is carried out in a modular manner, where developers in a development project team develop multiple program modules according to requirements, and these program modules are combined to achieve specific functions.

[0003] However, when a developer in a development project takes over a program module developed by others, he or she needs to reorganize the organizational logic of the program code and cannot quickly locate the code that needs to be modified.

[0004] Therefore, there is an urgent need for a technical solution that can process program modules so that other developers can quickly locate the code that needs to be modified in the program modules. Summary of the Invention

[0005] In view of this, the present application provides a method and apparatus for processing a program module as follows:

[0006] A method for processing a program module, applied to an electronic device, comprising:

[0007] Loading an entry file of at least one target program module, wherein the entry file is used to load the target program module; the target program module includes at least one program submodule, a data definition file, an interface definition file, and a configuration information file; the target program module can be loaded separately;

[0008] The data definition file is used to generate a data table model in a database, and the data table model is used for the target program module to implement corresponding functions; the interface definition file is used to generate a module interface of the program submodule, and the module interface is used to access the program submodule; the configuration information file is used to set parameter information of the program submodule;

[0009] Generate an interface tree and a module permission tree according to the interface directory information corresponding to the interface definition file, wherein the interface tree and the module permission tree are used to process the target program module;

[0010] The interface directory information represents the functional logical relationship of the program submodule in the target program module; the module identifiers corresponding to the program submodules contained in the interface tree are in a target directory structure, the module identifiers in the interface tree correspond to the interface definition files corresponding to the program submodules to which they belong, and the target directory structure matches the interface directory information;

[0011] Furthermore, the module identifiers of the program submodules contained in the module permission tree are in the target directory structure.

[0012] The above method, preferably, further comprises:

[0013] receiving a module access request, wherein the module access request includes an access identifier corresponding to a target submodule to be accessed;

[0014] According to the access identifier, obtaining a target permission tree corresponding to the target submodule in the module permission tree;

[0015] Comparing the target permission tree with the access permission tree corresponding to the module access request to obtain a comparison result;

[0016] In a case where the comparison result indicates that the target permission tree matches the access permission tree, access to the target submodule is allowed through a target interface, where the target interface is a module interface of the target submodule.

[0017] The above method preferably loads the entry file of at least one target program module, including:

[0018] Obtain a module directory, wherein the module directory contains module information of a program module to be loaded;

[0019] According to the order of the module information in the module directory, the entry file of the target program module corresponding to the module information is loaded.

[0020] The above method, preferably, further comprises:

[0021] Monitoring whether first information is added to the module directory;

[0022] In a case where first information is added to the module directory, loading an entry file of a first program module corresponding to the first information;

[0023] An interface tree and a module permission tree corresponding to the first program module are generated according to the interface directory information corresponding to the interface definition file contained in the first program module.

[0024] The above method, preferably, further comprises:

[0025] monitoring whether second information covers third information in the module directory;

[0026] If yes, loading the entry file of the second program module corresponding to the second information;

[0027] Based on the interface directory information corresponding to the interface definition file contained in the second program module, an interface tree and a module permission tree corresponding to the second program module are generated. The interface tree corresponding to the second program module covers the interface tree corresponding to the third program module corresponding to the third information, and the module permission tree corresponding to the second program module covers the module permission tree corresponding to the third program module.

[0028] The above method, preferably, further comprises:

[0029] monitoring whether a first submodule is added to the target program module and first directory information corresponding to the first submodule is newly created in an interface definition file corresponding to the target program module;

[0030] If yes, load the first submodule;

[0031] According to the first directory information, the interface tree and the module authority tree are updated so that the interface tree contains the module identifier of the first sub-module and the directory position of the module identifier of the first sub-module in the interface tree matches the position of the first sub-module in the target program module, and the module authority tree contains the module identifier of the first sub-module and the directory position of the module identifier of the first sub-module in the module authority tree matches the position of the first sub-module in the target program module.

[0032] The above method, preferably, further comprises:

[0033] monitoring whether a first interface definition file covers a second interface definition file in the interface tree, the second interface definition file corresponding to the second submodule;

[0034] If so, load the first interface definition file.

[0035] The above method, preferably, further comprises:

[0036] monitoring whether a program submodule in the target program module is split into a third submodule and a fourth submodule;

[0037] If yes, load the interface definition file corresponding to the third submodule and the interface definition file corresponding to the fourth submodule;

[0038] Update the interface tree and the module permission tree so that the directory position corresponding to the split program sub-module in the interface tree contains the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module, and the directory position corresponding to the split program sub-module in the module permission tree contains the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module.

[0039] The above method, preferably, further comprises:

[0040] monitoring whether a third submodule and a fourth submodule are merged in the target program module;

[0041] If yes, load the interface definition file corresponding to the third submodule and the interface definition file corresponding to the fourth submodule;

[0042] Update the interface tree and the module authority tree so that the module identifier corresponding to the third submodule and the module identifier corresponding to the fourth submodule in the interface tree are merged into the same directory location, and the module identifier corresponding to the third submodule and the module identifier corresponding to the fourth submodule in the module authority tree are merged into the same directory location.

[0043] A program module processing device, applied to an electronic device, comprising:

[0044] a module loading unit, configured to load an entry file of at least one target program module, wherein the entry file is used to load the target program module; the target program module includes at least one program submodule, a data definition file, an interface definition file, and a configuration information file; the target program module can be loaded individually;

[0045] The data definition file is used to generate a data table model in a database, and the data table model is used for the target program module to implement corresponding functions; the interface definition file is used to generate a module interface of the program submodule, and the module interface is used to access the program submodule; the configuration information file is used to set parameter information of the program submodule;

[0046] A tree generation unit, configured to generate an interface tree and a module permission tree according to the interface directory information corresponding to the interface definition file, wherein the interface tree and the module permission tree are used to process the target program module;

[0047] The interface directory information represents the functional logical relationship of the program submodule in the target program module; the module identifiers corresponding to the program submodules contained in the interface tree are in a target directory structure, the module identifiers in the interface tree correspond to the interface definition files corresponding to the program submodules to which they belong, and the target directory structure matches the interface directory information;

[0048] Furthermore, the module identifiers of the program submodules contained in the module permission tree are in the target directory structure.

[0049] As can be seen from the above technical solution, the present application provides a method and device for processing a program module. The developed program module includes an entry file, a program submodule, a data definition file, an interface definition file, and a configuration information file. When the program module is loaded on an electronic device, the program module is loaded by loading the entry file. Moreover, the data definition file is used to generate a data table model in a database, and the data table model is used for the target program module to implement the corresponding function. The interface definition file is used to generate a module interface of the program submodule, and the module interface is used to access the program submodule; the configuration information file is used to set the parameter information of the program submodule; in addition, an interface tree and a module permission tree are generated according to the interface directory information corresponding to the interface definition file. Thus, the interface tree and the module permission tree are used to process the target program module. Specifically, the interface directory information represents the functional logical relationship of the program submodule in the program module; the module identifier corresponding to the program submodule contained in the interface tree is in the target directory structure, the module identifier in the interface tree corresponds to the interface definition file corresponding to the program submodule to which it belongs, the target directory structure matches the interface directory information, and the module identifier of the program submodule contained in the module permission tree is in the target directory structure. It can be seen that the interface tree and module permission tree generated for the program module in this application present a directory structure that represents the functional logical relationship between the program sub-modules in the program module. Therefore, when a program sub-module needs to be accessed, the developer does not need to reorganize the organizational logic of his program code, and can quickly locate the program sub-module that needs to be accessed through the interface tree and module permission tree, thereby improving development efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0051] Figure 1 A flowchart of a method for processing a program module provided in Example 1 of the present application;

[0052] Figure 2 Another flowchart of a method for processing a program module provided in Example 1 of the present application;

[0053] Figure 3-Figure 9 They are respectively partial flow charts of a method for processing a program module provided in Example 1 of the present application;

[0054] Figure 10 A schematic diagram of the structure of a program module processing device provided in Example 2 of the present application;

[0055] Figure 11 Another structural diagram of a program module processing device provided in the second embodiment of the present application;

[0056] Figure 12 This is a structural diagram of an electronic device provided in Example 3 of the present application. DETAILED DESCRIPTION

[0057] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0058] refer to Figure 1 The figure shows a flowchart of a method for processing a program module according to the first embodiment of the present application. The method can be applied to electronic devices capable of loading programs, such as servers. The technical solution in this embodiment is mainly used to process program modules so that other developers can quickly locate the code that needs to be modified.

[0059] Specifically, the method in this embodiment may include the following steps:

[0060] Step 101: Loading an entry file of at least one target program module, where the target program module includes at least one program submodule, a data definition file, an interface definition file, and a configuration information file.

[0061] The entry file is used to load the target program module into the electronic device. Specifically, the entry file contains the module identifiers of the program submodules contained in the target program module. The module identifiers of the program submodules can uniquely identify the program submodules in the target program module and can also identify the functions that the program submodules can implement.

[0062] It should be noted that the target program module includes file data required for loading, such as a data definition file, an interface definition file, and a configuration information file, so that the target program module can be loaded separately.

[0063] Specifically, the data definition file is used to generate a data table model in the database, and the data table model is used for the target program module to implement the corresponding functions; the interface definition file is used to generate the module interface of the program sub-module, and the module interface is used to access the program sub-module. Each program sub-module corresponds to an interface definition file, and the interface positioning files corresponding to all program sub-modules constitute the interface definition file of the target program module; the configuration information file is used to set the parameter information of the program sub-module, so that the electronic device can use the parameter information in the configuration information file through the global configuration variables to set the configuration parameters of the target program module, so that the target program module loaded on the electronic device can implement specific functions, such as outputting certain data.

[0064] In one implementation, in this embodiment, a module base may be configured in the electronic device, and the module base is used to load the entry file of the target program module so that the target program module is loaded into the memory of the electronic device and can run normally.

[0065] Step 102: Generate an interface tree and a module permission tree according to the interface directory information corresponding to the interface definition file. The interface tree and the module permission tree are used to process the target program module.

[0066] Among them, the interface directory information represents the functional logical relationship of the program sub-module in the target program module. The module identifiers corresponding to the program sub-modules contained in the interface tree generated based on the interface directory information are in the target directory structure. The module identifiers in the interface tree correspond to the interface definition files corresponding to the program sub-modules to which they belong. The target directory structure matches the interface directory information, and the module identifiers of the program sub-modules contained in the module authority tree are in the target directory structure.

[0067] For example, developers can develop program modules according to the following specifications:

[0068] First, each program module does not rely strongly on any other program module except the module base, and each program module can be stored in an independent code library, so that each program module can be plug-and-play.

[0069] Secondly, program modules can be flexibly split into different forms and sizes to adapt to the arrangement of development workload.

[0070] In addition, the interface definition code files within the program module are organized in a directory hierarchy that conforms to the function definitions in the product logic. Interfaces with the same permissions can be stored in the same directory.

[0071] Based on this, each program module consists of the following parts:

[0072] Entry file: The module base reads the entry file in each program module to load the entire program module.

[0073] Configuration files contain configurable parameters used within a module. The module base provides global configuration information to override each module's default configuration, allowing for customized functionality based on the module's user. A module's configuration information can include other modules it depends on. In this case, the module base will load only the dependent modules, and then load the modules that depend on them.

[0074] Data definition files: A program module may or may not have data definitions. If they do, they are used to generate the data table model (also referred to as the data model) in the database. Program modules can extend the definition of data models. The data definition in a later loaded program module will extend or overwrite the data model of the same name in the earlier loaded module.

[0075] Interface definition file: defines all interfaces that need to be exposed in the program module. The internal form is constructed according to the definition of the program module in the product logic and the authority division to build a directory structure, and the code of each interface is placed in a different subdirectory.

[0076] Other files: Each program module may require some other supporting codes or encapsulated reusable codes. The creation and use of these files are entirely determined by the developer of the program module. The specifications in this embodiment do not restrict them to maximize the coding capabilities of developers.

[0077] Accordingly, the module base defines the module storage location and automatically loads each module from this location. It also generates an interface tree and an interface permission tree (the module permission tree mentioned above) by reading the interface directory of each module. When an interface request is made, the user permission tree of the current requesting user and the interface permission tree of the requested interface are used to determine whether the user has permission to access the interface.

[0078] For example, the interface directory information corresponding to the target program module's interface definition file is: directory a, directory a has a subdirectory b, subdirectory b has subdirectories c, subdirectory d, and subdirectories c and d each contain an interface definition file. Furthermore, the interface directory information represents the corresponding target directory structure. Based on this, the target program module contains interfaces: a / b / c and a / b / d. The corresponding interface tree and module permission tree (i.e., interface permission tree) are:

[0079]

[0080] Therefore, both the interface tree and the module permission tree present the above target directory structure.

[0081] It can be seen that in a method for processing a program module provided in the first embodiment of the present application, the developed program module includes an entry file, a program submodule, a data definition file, an interface definition file, and a configuration information file. When the program module is loaded on an electronic device, the loading of the program module is realized by loading the entry file. Moreover, the data definition file is used to generate a data table model in the database, and the data table model is used for the target program module to implement the corresponding function. The interface definition file is used to generate a module interface of the program submodule, and the module interface is used to access the program submodule; the configuration information file is used to set the parameter information of the program submodule; in addition, an interface tree and a module permission tree are generated according to the interface directory information corresponding to the interface definition file. Thus, the interface tree and the module permission tree are used to process the target program module. Specifically, the interface directory information represents the functional logical relationship of the program submodule in the program module; the module identifier corresponding to the program submodule contained in the interface tree is in the target directory structure, the module identifier in the interface tree corresponds to the interface definition file corresponding to the program submodule to which it belongs, the target directory structure matches the interface directory information, and the module identifier of the program submodule contained in the module permission tree is in the target directory structure. It can be seen that the interface tree and module permission tree generated for the program module in this embodiment present a directory structure that represents the functional logical relationship between the program sub-modules in the program module. Therefore, when a program sub-module needs to be accessed, the developer does not need to reorganize the organizational logic of his program code, and can quickly locate the program sub-module that needs to be accessed through the interface tree and module permission tree, thereby improving development efficiency.

[0082] Furthermore, in this embodiment, the program submodules are generated into an interface tree and a model permission tree according to their functional logical relationships in the program modules, so that access to any program submodule is not affected by the coupling between the program submodules.

[0083] Based on the above implementation scheme, this embodiment may also include the following steps: Figure 2 As shown in:

[0084] Step 103: Receive a module access request, where the module access request includes an access identifier corresponding to a target submodule to be accessed.

[0085] Each module access request corresponds to an access rights tree, which represents the current access rights status of the user to whom the module access request relates. This access rights tree can be determined by identifying the user to whom the module access request relates. For example, based on the module access request, the user is identified and the pre-configured access rights tree for that user is obtained.

[0086] For example, when a user needs to access a target submodule, he or she can generate a module access request through his or her terminal. The module identifier of the target submodule is added to the module access request, which is the access identifier. In addition, the user has his or her own user permissions, which is the access permission tree. The access permission tree is as follows:

[0087]

[0088] Step 104: According to the access identifier, obtain the target permission tree corresponding to the target submodule in the module permission tree.

[0089] Specifically, in this embodiment, identifier matching is performed in the module permission tree according to the access identifier to match the target permission tree corresponding to the target submodule, and the target permission tree corresponds to the directory location of the target submodule.

[0090] For example, according to the module identifier of the target submodule, ie, the access identifier a / b / d, the target permission tree, ie, a / b / d, is obtained in the module permission tree.

[0091] Step 105: Compare the target permission tree with the access permission tree to obtain a comparison result.

[0092] For example, it is determined whether the target permission tree is included in the directory structure of the access permission tree to obtain a comparison result indicating whether the target permission tree matches the access permission tree.

[0093] For example, taking the target permission tree a / b / d as an example, the target permission tree a / b / d is not in the access permission tree a / b / c, and a comparison result is obtained indicating that the target permission tree and the access permission tree do not match.

[0094] For another example, taking the target permission tree a / b / c as an example, the target permission tree a / b / c is placed in the access permission tree a / b / c to obtain a comparison result indicating that the target permission tree matches the access permission tree.

[0095] Step 106: Determine whether the comparison result indicates that the target permission tree matches the access permission tree. If the comparison result indicates that the target permission tree matches the access permission tree, execute step 107. If the comparison result indicates that the target permission tree does not match the access permission tree, then end the current process.

[0096] Step 107: allowing access to the target submodule through the target interface, where the target interface is the module interface of the target submodule.

[0097] For example, taking the target permission tree a / b / d as an example, the target permission tree a / b / d is not in the user's access permission tree a / b / c, and the comparison result is obtained indicating that the target permission tree and the access permission tree do not match. At this time, access to the target sub-module a / b / d through the module interface of the target sub-module is not allowed.

[0098] For example, taking the target permission tree a / b / c as an example, the target permission tree a / b / c is in the user's access permission tree a / b / c, and a comparison result is obtained that indicates that the target permission tree matches the access permission tree. At this time, access to the target sub-module a / b / c is allowed through the module interface of the target sub-module.

[0099] In one implementation, when loading the entry file of at least one target program module in step 101, it can be implemented in the following manner: Figure 3 As shown in:

[0100] Step 301: Obtain a module directory, which contains module information of a program module to be loaded.

[0101] The module information may include a storage address of the program module to be loaded in the electronic device, so as to instruct to load the program module according to the storage address.

[0102] In addition, a module directory may contain multiple module information, which are stored in a specific order within the module directory. The specific order of module information can be pre-set by personnel (such as system integrators or module users), or can be set based on the project requirements of the development project to which the program module belongs.

[0103] Step 302: Load the entry file of the target program module corresponding to the module information according to the order of the module information in the module directory.

[0104] Specifically, the module base configured on the electronic device reads the module information in the module directory, and loads the entry files of the target program modules corresponding to these module information in sequence according to the order of the module information in the read module directory, and then loads the target program module into the memory of the electronic device through the entry file, so that the target program module can run and obtain the corresponding function.

[0105] For example, the module base in the electronic device can load all program modules in a specified order, including the data definition, configuration information, interface definition and other files of the program modules. It can also use the global configuration information to overwrite the module configuration and generate a data model. At the same time, it exposes the interfaces of all modules and starts the permission controller, and implements access control of each interface in the program module through the module permission tree.

[0106] Specifically, the module base implements module loading through the following process:

[0107] First, load the entry file of the program module, then read the configuration information of the program module, and read the module data definition to generate a data model. At the same time, read the module interface definition and generate an interface tree and module permission tree according to the directory structure of the interface definition.

[0108] Based on this, when users access program modules, permission control can be performed in the following ways:

[0109] First, obtain the permission information of the current user through the front-end request interface. Then, compare the permission in the module permission tree corresponding to the location of the requested interface in the interface tree with the corresponding permission in the current user permission tree. If there is permission, it will be released. If not, an error will be returned directly.

[0110] For example, the module's interface directory contains a directory a, a subdirectory b, and two subdirectories c and d. Each of c and d contains an interface definition file. This module then has the following interfaces: a / b / c, a / b / d. The corresponding interface tree and interface permission tree are:

[0111]

[0112]

[0113] And there is a user's permission tree:

[0114]

[0115] When this user accesses a / b / c, the module base will allow access; when this user accesses a / b / d, the module base will return an error and not allow access.

[0116] Furthermore, this embodiment may also include the following steps: Figure 4 As shown in:

[0117] Step 303: Monitor whether the first information is added to the module directory. If the first information is added to the module directory, execute step 304. If the first information is not added to the module directory, no other processing is performed and step 303 is continued to monitor whether the first information is added to the module directory.

[0118] Step 304: Load the entry file of the first program module corresponding to the first information.

[0119] Step 305: Generate an interface tree and a module permission tree corresponding to the first program module according to the interface directory information corresponding to the interface definition file included in the first program module.

[0120] For example, when a new program module needs to be loaded, the developer develops the new program module and places the newly added program module into the module directory specified by the module base. As a result, the new program module will be automatically loaded by the module base. For example, the module information of the first program module f is added to the module directory. The module base in this embodiment loads the entry file of f and generates the interface tree and module permission tree of f. The structure of the interface tree and module permission tree of f can refer to the structure of the interface tree and module permission tree of the target program module a.

[0121] In one implementation, the method in this embodiment may further include the following steps: Figure 5 As shown in:

[0122] Step 306: Monitor whether the second information in the module directory covers the third information. If so, execute step 307. If not, continue to execute step 306 to continue monitoring whether the second information in the module directory covers the third information.

[0123] The third information is module information of a loaded program module recorded as a third program module, and the second information is module information of a second program module that replaces the third program module corresponding to the third information.

[0124] Step 307: Load the entry file of the second program module corresponding to the second information.

[0125] Step 308: Based on the interface directory information corresponding to the interface definition file contained in the second program module, generate an interface tree and a module permission tree corresponding to the second program module. The interface tree corresponding to the second program module covers the interface tree corresponding to the third program module corresponding to the third information, and the module permission tree corresponding to the second program module covers the module permission tree corresponding to the third program module.

[0126] For example, the module information of the second program module h in the module directory covers the third program module i. The module base in this embodiment loads the entry file of h and generates the interface tree and module permission tree of h, whose structure can refer to the structure of the interface tree and module permission tree of the target program module a, and the interface tree and module permission tree of h cover the interface tree and module permission tree of i.

[0127] For example, after loading a program module into the module base, if the entire loaded program module needs to be replaced with another program module, the developer only needs to write the new program module and place it in the module directory specified by the module base, replacing the module information of the original program module. Based on this, the module base will automatically load the new program module. Suppose that the currently loaded program module is no longer needed for some reason, and the developer needs a new program module to replace or expand it. The developer only needs to develop the new program module, place its entire program module directory in the module directory specified by the module base, and delete the directory corresponding to the original program module.

[0128] In one implementation, the method in this embodiment may further include the following steps: Figure 6 As shown in:

[0129] Step 601: Monitor whether the first submodule is added to the target program module and whether the first directory information corresponding to the first submodule is newly created in the interface definition file corresponding to the target program module. If so, execute step 602; if not, continue to execute step 601 to continue monitoring whether the first submodule is added to the target program module.

[0130] Step 602: Load the first submodule.

[0131] Step 603: Based on the first directory information, update the interface tree and the module permission tree so that the interface tree contains the module identifier of the first submodule and the directory position of the module identifier of the first submodule in the interface tree matches the position of the first submodule in the target program module, and the module permission tree contains the module identifier of the first submodule and the directory position of the module identifier of the first submodule in the module permission tree matches the position of the first submodule in the target program module.

[0132] Thus, the added program submodules can be accessed through the interface tree and the module permission tree. For example, when adding a new function to the loaded program module, a new subdirectory is created in the directory structure formed by the interface definition file of the program module, in which the developer can write the new interface definition code. Based on this, the module base will automatically load the new interface. Assume that when a function needs to be added to the module, the corresponding interface is under b, but different from c and d. The developer only needs to create a new directory e in b and define the new interface in e. Then the module base will automatically generate the interface routing and permission control corresponding to a / b / e.

[0133] For example, after the module base detects that a / b / e is added to the target program module a and that directory information of a / b / e is newly created, the module base loads the submodules of a / b / e and updates the interface tree and module permission tree of a as follows:

[0134]

[0135]

[0136] In one implementation, the method in this embodiment may further include the following steps: Figure 5 As shown in:

[0137] Step 701: Monitor whether there is a first interface definition file covering a second interface definition file in the interface tree, the second interface definition file corresponding to the second submodule. If so, execute step 702.

[0138] Step 5702: Load the first interface definition file.

[0139] Therefore, in this embodiment, only the first interface definition file needs to be loaded to implement interface update.

[0140] For example, when replacing existing functionality in a loaded program module, a developer can locate the directory containing the interface to be replaced within the program module and then write new interface code to replace the original file. The new interface file name, number of files, and file structure do not need to be identical to the original code file. Based on this, the module base will automatically load the new interface definition. Suppose the functionality of interfaces a / b / c needs to be adjusted, and another developer has already written the interface code file. Simply place the new interface definition file in the a / b / c directory and delete the original interface definition file in this directory. The new interface definition file does not need to be internally related to the original interface definition file; as long as the exposed interface is consistent, it is sufficient.

[0141] In one implementation, the method in this embodiment may further include the following steps: Figure 8 As shown in:

[0142] Step 801: Monitor whether a program submodule in the target program module is split into a third submodule and a fourth submodule. If so, execute step 802. If not, continue to execute step 801 to continue monitoring whether a program submodule in the target program module is split into a third submodule and a fourth submodule.

[0143] Step 802: Load the interface definition file corresponding to the third submodule and the interface definition file corresponding to the fourth submodule.

[0144] Step 803: Update the interface tree and the module permission tree so that the directory location corresponding to the split program sub-module in the interface tree contains the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module, and the directory location corresponding to the split program sub-module in the module permission tree contains the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module.

[0145] For example, if new product feature permissions require that functions with the same permissions be split into multiple permissions, the directory corresponding to the original interface definition file can be split into multiple directories. If the original interface definition file is independent, simply place the split program submodules into different subdirectories. If the original interface definition file is in a single file, split the different interface codes into different files and place them in different subdirectories. As a result, the module base will automatically load the new interface definition file and control access according to the new module permission tree.

[0146] In one implementation, the method in this embodiment may further include the following steps: Figure 9 As shown in:

[0147] Step 901: Monitor whether the third submodule and the fourth submodule are merged in the target program module. If so, execute step 902. If not, continue to execute step 901 to continue monitoring whether the third submodule and the fourth submodule are merged in the target program module.

[0148] Step 902: Load the interface definition file corresponding to the third submodule and the interface definition file corresponding to the fourth submodule.

[0149] Step 903: Update the interface tree and the module authority tree so that the module identifier corresponding to the third submodule and the module identifier corresponding to the fourth submodule in the interface tree are merged into the same directory location, and the module identifier corresponding to the third submodule and the module identifier corresponding to the fourth submodule in the module authority tree are merged into the same directory location.

[0150] For example, if new product feature permissions change functions that previously had different permissions to the same permissions, simply merge the interface definition files from different subdirectories into the same directory. If the original interface definition files were independent, there's no need to merge them; simply place them in the same directory. Based on this, the module base will automatically load the new interface definition and control access based on the new permissions structure.

[0151] For example, suppose that under the product function corresponding to interface a / b / c, two functions with different permissions need to be differentiated, named c1 and c2. At this time, the developer only needs to divide the original interface definition file in a / b / c into two parts as needed, and save them in the a / b / c1 and a / b / c2 subdirectories respectively. Based on this, the module base can directly load the new interface definition file and control access according to the new permission structure.

[0152] The original a / b / d and a / b / e will require exactly the same permissions from the product logic, so developers only need to move the code files in the directories a / b / d and a / b / e to some (the directory name can be determined as needed, or d or e can be used directly).

[0153] refer to Figure 10 , is a structural diagram of a program module processing device provided in the second embodiment of the present application. The device can be configured in an electronic device, such as a server. The device in this embodiment may include the following units:

[0154] The loading unit 1001 is used to load an entry file of at least one target program module, wherein the entry file is used to load the target program module; the target program module includes at least one program submodule, a data definition file, an interface definition file, and a configuration information file; the target program module can be loaded individually;

[0155] Among them, the data definition file is used to generate a data table model in the database, and the data table model is used for the target program module to implement corresponding functions; the interface definition file is used to generate the module interface of the program sub-module, and the module interface is used to access the program sub-module; the configuration information file is used to set the parameter information of the program sub-module.

[0156] Specifically, the loading unit 1001 is specifically used to: obtain a module directory, which contains module information of the program module to be loaded; and load the entry file of the target program module corresponding to the module information in the order of the module information in the module directory.

[0157] A tree generation unit 1002 is configured to generate an interface tree and a module permission tree according to the interface directory information corresponding to the interface definition file, wherein the interface tree and the module permission tree are used to process the target program module;

[0158] The interface directory information represents the functional logical relationship of the program submodule in the target program module; the module identifiers corresponding to the program submodules contained in the interface tree are in a target directory structure, the module identifiers in the interface tree correspond to the interface definition files corresponding to the program submodules to which they belong, and the target directory structure matches the interface directory information;

[0159] Furthermore, the module identifiers of the program submodules contained in the module permission tree are in the target directory structure.

[0160] It can be seen that in the processing device of a program module provided in the second embodiment of the present application, the developed program module includes an entry file, a program submodule, a data definition file, an interface definition file and a configuration information file. When the program module is loaded on the electronic device, the loading of the program module is realized by loading the entry file. Moreover, the data definition file is used to generate a data table model in the database, and the data table model is used for the target program module to implement the corresponding function. The interface definition file is used to generate the module interface of the program submodule, and the module interface is used to access the program submodule; the configuration information file is used to set the parameter information of the program submodule; in addition, according to the interface directory information corresponding to the interface definition file, an interface tree and a module permission tree are generated. Thus, the interface tree and the module permission tree are used to process the target program module. Specifically, the interface directory information represents the functional logical relationship of the program submodule in the program module; the module identifier corresponding to the program submodule contained in the interface tree is in the target directory structure, the module identifier in the interface tree corresponds to the interface definition file corresponding to the program submodule to which it belongs, the target directory structure matches the interface directory information, and the module identifier of the program submodule contained in the module permission tree is in the target directory structure. It can be seen that the interface tree and module permission tree generated for the program module in this embodiment present a directory structure that represents the functional logical relationship between the program sub-modules in the program module. Therefore, when a program sub-module needs to be accessed, the developer does not need to reorganize the organizational logic of his program code, and can quickly locate the program sub-module that needs to be accessed through the interface tree and module permission tree, thereby improving development efficiency.

[0161] Furthermore, in this embodiment, the program submodules are generated into an interface tree and a model permission tree according to their functional logical relationships in the program modules, so that access to any program submodule is not affected by the coupling between the program submodules.

[0162] In one implementation, the apparatus in this embodiment may further include other units, such as Figure 11 As shown in:

[0163] The access control unit 1003 is used to receive a module access request, wherein the module access request includes an access identifier, and the access identifier corresponds to the target sub-module to be accessed; based on the access identifier, a target permission tree corresponding to the target sub-module is obtained in the module permission tree; the target permission tree is compared with the access permission tree corresponding to the module access request to obtain a comparison result; if the comparison result indicates that the target permission tree matches the access permission tree, access to the target sub-module is allowed through a target interface, and the target interface is the module interface of the target sub-module.

[0164] The module processing unit 1004 is used to monitor whether the first information is added to the module directory; when the first information is added to the module directory, load the entry file of the first program module corresponding to the first information; and generate the interface tree and module permission tree corresponding to the first program module according to the interface directory information corresponding to the interface definition file contained in the first program module.

[0165] Preferably, the module processing unit 1004 is also used to: monitor whether the second information in the module directory covers the third information; if so, load the entry file of the second program module corresponding to the second information; generate an interface tree and a module permission tree corresponding to the second program module according to the interface directory information corresponding to the interface definition file contained in the second program module, the interface tree corresponding to the second program module covers the interface tree corresponding to the third program module corresponding to the third information, and the module permission tree corresponding to the second program module covers the module permission tree corresponding to the third program module.

[0166] Preferably, the module processing unit 1004 is also used to: monitor whether a first submodule is added to the target program module and whether a first directory information corresponding to the first submodule is newly created in the interface definition file corresponding to the target program module; if so, load the first submodule; update the interface tree and the module permission tree according to the first directory information, so that the interface tree contains the module identifier of the first submodule and the directory position of the module identifier of the first submodule in the interface tree matches the position of the first submodule in the target program module, and, the module permission tree contains the module identifier of the first submodule and the directory position of the module identifier of the first submodule in the module permission tree matches the position of the first submodule in the target program module.

[0167] Preferably, the module processing unit 1004 is further used to: monitor whether there is a first interface definition file covering a second interface definition file in the interface tree, the second interface definition file corresponding to the second sub-module; if so, load the first interface definition file.

[0168] Preferably, the module processing unit 1004 is also used to: monitor whether a program sub-module in the target program module is split into a third sub-module and a fourth sub-module; if so, load the interface definition file corresponding to the third sub-module and the interface definition file corresponding to the fourth sub-module; update the interface tree and the module authority tree so that the directory position corresponding to the split program sub-module in the interface tree contains the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module, and the directory position corresponding to the split program sub-module in the module authority tree contains the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module.

[0169] Preferably, the module processing unit 1004 is also used to: monitor whether the third sub-module and the fourth sub-module are merged in the target program module; if so, load the interface definition file corresponding to the third sub-module and the interface definition file corresponding to the fourth sub-module; update the interface tree and the module permission tree so that the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module in the interface tree are merged into the same directory location, and the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module in the module permission tree are merged into the same directory location.

[0170] It should be noted that the specific implementation of each unit in this embodiment can refer to the corresponding content in the previous text and will not be described in detail here.

[0171] refer to Figure 12 , is a schematic diagram of the structure of an electronic device provided in Example 3 of the present application, and the electronic device may include the following structure:

[0172] Memory 1201, used to store computer programs and data generated by the execution of the computer programs;

[0173] Processor 1202 is configured to execute a computer program to implement: loading an entry file of at least one target program module, the entry file being used to load the target program module; the target program module including at least one program submodule, a data definition file, an interface definition file, and a configuration information file; the target program module can be loaded separately; wherein the data definition file is used to generate a data table model in a database, the data table model being used for the target program module to implement corresponding functions; the interface definition file being used to generate a module interface of the program submodule, the module interface being used to access the program submodule; the configuration information file being used to set the program submodule; parameter information of the program sub-module; according to the interface directory information corresponding to the interface definition file, an interface tree and a module permission tree are generated, and the interface tree and the module permission tree are used to process the target program module; wherein, the interface directory information represents the functional logical relationship of the program sub-module in the target program module; the module identifier corresponding to the program sub-module contained in the interface tree is in a target directory structure, the module identifier in the interface tree corresponds to the interface definition file corresponding to the program sub-module to which it belongs, and the target directory structure matches the interface directory information; and the module identifier of the program sub-module contained in the module permission tree is in the target directory structure.

[0174] It can be seen that in an electronic device provided by Example 3 of the present application, the developed program module includes an entry file, a program submodule, a data definition file, an interface definition file and a configuration information file. When the program module is loaded on the electronic device, the loading of the program module is realized by loading the entry file. Moreover, the data definition file is used to generate a data table model in the database, and the data table model is used for the target program module to implement the corresponding function. The interface definition file is used to generate the module interface of the program submodule, and the module interface is used to access the program submodule; the configuration information file is used to set the parameter information of the program submodule; in addition, according to the interface directory information corresponding to the interface definition file, an interface tree and a module permission tree are generated. Thus, the interface tree and the module permission tree are used to process the target program module. Specifically, the interface directory information represents the functional logical relationship of the program submodule in the program module; the module identifier corresponding to the program submodule contained in the interface tree is in the target directory structure, the module identifier in the interface tree corresponds to the interface definition file corresponding to the program submodule to which it belongs, the target directory structure matches the interface directory information, and the module identifier of the program submodule contained in the module permission tree is in the target directory structure. In this embodiment, the interface tree and module permission tree generated for the program module present a directory structure that represents the functional logical relationship between the program sub-modules in the program module. Therefore, when a program sub-module needs to be accessed, the developer does not need to reorganize the organizational logic of its program code, and can quickly locate the program sub-module that needs to be accessed through the interface tree and module permission tree, thereby improving development efficiency.

[0175] Furthermore, in this embodiment, the program submodules are generated into an interface tree and a model permission tree according to their functional logical relationships in the program modules, so that access to any program submodule is not affected by the coupling between the program submodules.

[0176] In summary, the technical solution of this application has the following advantages:

[0177] First, because the core content of the backend module is the interface definition, and the interface definition files in the program modules in this application are organized according to a directory structure, it is easy to split a relatively large program module into multiple small modules. You only need to assign the interface definition file directory to different program modules. The directory structure in different program modules can be repeated, and the module base will automatically merge them. In this way, the final effect of loading multiple small modules is the same as adding them directly to a large module. Modules can also be split according to actual circumstances, thereby making full use of the resources of the development team.

[0178] Secondly, this application does not have any common components that all program modules rely on. Each program module can be developed independently on the module base. Each program module in this application is self-contained and can run independently on the module base, so each developer only needs to obtain the module base and the program module they are responsible for, fully ensuring code security.

[0179] Thirdly, the interface planning within the program module is consistent with the product logic planning and its directory structure, making communication between developers and product managers more efficient. Furthermore, because the interface definitions within the module are organized in a directory structure that is consistent with the product logic, when a developer takes over a module developed by someone else, it is easy to locate the part that needs to be modified. Because the interface permissions are consistent with the directory structure, which is derived from the definition of the product logic, there is no need to consider permission control within the interface. Permission control is completely handled uniformly by the module base, which greatly improves the efficiency of interface coding, reduces the probability of errors, and reduces the complexity and duplication of code.

[0180] In addition, because the interface definitions within the module are organized in a directory structure, when you need to add a new functional interface, you only need to write the code in the newly added subdirectory or add a new code file in the existing subdirectory. There is no need to move other existing code files, which greatly reduces the coupling of code files and the probability of errors.

[0181] Finally, this application unifies the permission tree with the interface tree and directory interface. This way, after configuring permissions, the interface code doesn't need to consider the current user's role and permissions; it only needs to consider the business logic. Furthermore, this application defines the data model within the module, giving developers complete control over the internal data model. Furthermore, other modules can extend the data model definitions of other modules when necessary, without redefining the entire data model. Instead, they can define only the parts they need to extend.

[0182] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. Reference can be made to the common and similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method description.

[0183] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may 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.

[0184] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in a random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0185] The above description of the disclosed embodiments is intended to enable one skilled in the art to implement or use the present application. Various modifications to these embodiments will be readily apparent to one skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application is not limited to the embodiments shown herein, but is intended to conform to the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for processing a program module, characterized in that: Applied to electronic equipment, the method includes: Loading an entry file of at least one target program module, wherein the entry file is used to load the target program module; the target program module includes at least one program submodule, a data definition file, an interface definition file, and a configuration information file; the target program module can be loaded separately; The data definition file is used to generate a data table model in a database, and the data table model is used for the target program module to implement corresponding functions; the interface definition file is used to generate a module interface of the program submodule, and the module interface is used to access the program submodule; the configuration information file is used to set parameter information of the program submodule; Generate an interface tree and a module permission tree according to the interface directory information corresponding to the interface definition file, wherein the interface tree and the module permission tree are used to process the target program module; The interface directory information represents the functional logical relationship of the program submodule in the target program module; the module identifiers corresponding to the program submodules contained in the interface tree are in a target directory structure, the module identifiers in the interface tree correspond to the interface definition files corresponding to the program submodules to which they belong, and the target directory structure matches the interface directory information; Furthermore, the module identifiers of the program submodules contained in the module permission tree are in the target directory structure.

2. The method according to claim 1, characterized in that The method further comprises: receiving a module access request, wherein the module access request includes an access identifier corresponding to a target submodule to be accessed; According to the access identifier, obtaining a target permission tree corresponding to the target submodule in the module permission tree; Comparing the target permission tree with the access permission tree corresponding to the module access request to obtain a comparison result; In a case where the comparison result indicates that the target permission tree matches the access permission tree, access to the target submodule is allowed through a target interface, where the target interface is a module interface of the target submodule.

3. The method according to claim 1 or 2, characterized in that Load at least one target program module's entry file, including: Obtain a module directory, wherein the module directory contains module information of a program module to be loaded; According to the order of the module information in the module directory, the entry file of the target program module corresponding to the module information is loaded.

4. The method according to claim 3, characterized in that The method further comprises: Monitoring whether first information is added to the module directory; In a case where first information is added to the module directory, loading an entry file of a first program module corresponding to the first information; An interface tree and a module permission tree corresponding to the first program module are generated according to the interface directory information corresponding to the interface definition file contained in the first program module.

5. The method according to claim 3, characterized in that The method further comprises: monitoring whether second information covers third information in the module directory; If yes, loading the entry file of the second program module corresponding to the second information; Based on the interface directory information corresponding to the interface definition file contained in the second program module, an interface tree and a module permission tree corresponding to the second program module are generated. The interface tree corresponding to the second program module covers the interface tree corresponding to the third program module corresponding to the third information, and the module permission tree corresponding to the second program module covers the module permission tree corresponding to the third program module.

6. The method according to claim 1 or 2, characterized in that The method further comprises: monitoring whether a first submodule is added to the target program module and first directory information corresponding to the first submodule is newly created in an interface definition file corresponding to the target program module; If yes, load the first submodule; According to the first directory information, the interface tree and the module authority tree are updated so that the interface tree contains the module identifier of the first sub-module and the directory position of the module identifier of the first sub-module in the interface tree matches the position of the first sub-module in the target program module, and the module authority tree contains the module identifier of the first sub-module and the directory position of the module identifier of the first sub-module in the module authority tree matches the position of the first sub-module in the target program module.

7. The method according to claim 1 or 2, characterized in that The method further comprises: monitoring whether a first interface definition file covers a second interface definition file in the interface tree, the second interface definition file corresponding to the second submodule; If so, load the first interface definition file.

8. The method according to claim 1 or 2, characterized in that The method further comprises: monitoring whether a program submodule in the target program module is split into a third submodule and a fourth submodule; If yes, load the interface definition file corresponding to the third submodule and the interface definition file corresponding to the fourth submodule; Update the interface tree and the module permission tree so that the directory position corresponding to the split program sub-module in the interface tree contains the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module, and the directory position corresponding to the split program sub-module in the module permission tree contains the module identifier corresponding to the third sub-module and the module identifier corresponding to the fourth sub-module.

9. The method according to claim 1 or 2, characterized in that The method further comprises: monitoring whether a third submodule and a fourth submodule are merged in the target program module; If yes, load the interface definition file corresponding to the third submodule and the interface definition file corresponding to the fourth submodule; Update the interface tree and the module authority tree so that the module identifier corresponding to the third submodule and the module identifier corresponding to the fourth submodule in the interface tree are merged into the same directory location, and the module identifier corresponding to the third submodule and the module identifier corresponding to the fourth submodule in the module authority tree are merged into the same directory location.

10. A program module processing device, characterized in that: Applied to electronic equipment, the device comprises: a module loading unit, configured to load an entry file of at least one target program module, wherein the entry file is used to load the target program module; the target program module includes at least one program submodule, a data definition file, an interface definition file, and a configuration information file; the target program module can be loaded individually; The data definition file is used to generate a data table model in a database, and the data table model is used for the target program module to implement corresponding functions; the interface definition file is used to generate a module interface of the program submodule, and the module interface is used to access the program submodule; the configuration information file is used to set parameter information of the program submodule; A tree generation unit, configured to generate an interface tree and a module permission tree according to the interface directory information corresponding to the interface definition file, wherein the interface tree and the module permission tree are used to process the target program module; The interface directory information represents the functional logical relationship of the program submodule in the target program module; the module identifiers corresponding to the program submodules contained in the interface tree are in a target directory structure, the module identifiers in the interface tree correspond to the interface definition files corresponding to the program submodules to which they belong, and the target directory structure matches the interface directory information; Furthermore, the module identifiers of the program submodules contained in the module permission tree are in the target directory structure.

Images