MEF and Unity-based component modularization method
By defining the module interface and generating version number, the combination module forms a package version, and uses the unity and MEF container management module to solve the problem of performance, dependence and version control in existing technology, and achieve efficient and stable component modules. Management.
Patent Information
- Application Number
- CN202411128013.7
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-08-16
- Publication Date
- 2025-01-21
AI Technical Summary
The existing modular method of component based on MEF and Unity has performance problems, dependency problems and version control problems, resulting in longer application startup time, increased memory usage, complex module loading and initialization, and difficult to manage dependencies between modules and Version compatibility.
By defining the predetermined attributes and interfaces of the module, multiple interfaces of the module are generated, and the compiled resources are uploaded to the server to generate a version number. Combine multiple modules as needed to form a package version, and use the build.config file to define dependencies and orchestration rules. When the client starts, synchronize the build.config configuration, compare version numbers and perform upgrades and updates. Use Unity container and MEF combined container to manage dependencies and initialization between modules.
It achieves more efficient module loading and initialization, reduces application startup time and memory usage, simplifies dependency management and version control between modules, and improves system stability and maintainability.
Smart Images
Figure CN119336400A_ABST
Abstract
Description
Technical Field
[0001] The invention relates to the field of medical electronic platform, and in particular to a component modularization method based on MEF and Unity. Background Art
[0002] The modular design of components makes each functional component independent of each other through the interaction between MEF technology and Unity technology. MEF is an extensibility framework of .NET Framework, which allows applications to dynamically load and discover components at runtime. Unity is a lightweight dependency injection container that can help us manage objects and components in applications.
[0003] The framework combination implements component modularity, and the general steps are as follows: Create a MEF plug-in project, which will contain all pluggable components. In the plug-in project, use MEF attributes to mark all pluggable components. This will make the MyComponent class a pluggable component and can be dynamically loaded at runtime. In the main application, create a Unity container and use MEF attributes to mark all pluggable components. This will enable the main application to dynamically load all pluggable components and inject them into the Components property. In the main application, use the Unity container to instantiate and manage all components. This will enable the main application to use the Unity container to instantiate and manage all components, and can dynamically load and discover components at runtime. Through the above steps, you can use MEF Unity technology to implement component modularity. Using MEF Unity technology to implement modularity requires certain technical knowledge and experience. This may increase the complexity of the project and lead to more maintenance and support work. Using MEF Unity technology to implement modularity may cause performance issues because each module needs to be loaded and initialized. This may cause the startup time of the application to be slower and increase memory usage. Using MEF Unity to implement modularity can cause dependency issues. If one module depends on another module, there may be problems loading and initializing the module. Using MEF Unity to implement modularity can cause versioning issues. If one module is updated, other modules may need to be updated accordingly to be compatible with it. Summary of the invention
[0004] Therefore, the present invention proposes the following solution: a component modularization method based on MEF and Unity, comprising the following steps: Step 1, defining a module according to predetermined attributes, and then forming multiple interfaces of the module according to the definition; Step 2, uploading the compiled resources to the server and generating a version number of the module in the corresponding module on the server; Step 3, combining multiple modules as needed to form a desired package version with a build.config file, wherein the build.config file defines the modules and arrangement rules on which the current package depends.
[0005] Preferably, step 4 is also included, when starting the client, synchronizing the build.config configuration, comparing the build.config configuration with the module version number in the local version.config configuration, and upgrading and updating accordingly, and writing the corresponding content into the local version.config.
[0006] Preferably, the predetermined attributes include methods, properties and events of the module.
[0007] Preferably, after all modules are loaded according to the configuration, the orchestration rules in build.config are read and loaded into the scheduling engine, the scheduling engine loads the corresponding modules according to the orchestration rules, creates a Unity container and a MEF composite container locally, and marks them as exportable modules using the Export attribute, injects dependencies between modules using the ImportingConstructor attribute, and adds the Unity container to the MEF container using the ComposeParts method.
[0008] When the application starts, the initialization process is executed, and the program submits the scheduling task to the scheduling engine. Before executing the scheduling, the scheduling engine first reads the rule configuration in build.config. This rule is the public rule of the user package. If the customer is online, it will query the cloud to pull the customer's custom module configuration rule. This rule is the customer's private rule. According to the combination of public rules and private rules, the initialization process node is generated for the customer based on the module dependency, and the orchestrated node is stored in the scheduling engine container. At this time, the life cycle of the scheduling engine module pull is triggered, and the required dependency modules are pulled on demand from the local module warehouse (the local module warehouse will maintain the required dependencies when starting the update). After all modules are ready, the modules are started in sequence through the scheduling engine execution unit. After all modules are started, the initialization process ends and the application startup is completed. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Figure 1-6 A simplified diagram of the module interface process, module compilation process, module distribution process, module initialization process, module calling process, and modular UI process of the present invention is shown. DETAILED DESCRIPTION
[0010] like Figure 1 As shown, first you need to define the interface of each module, including the module's methods, properties, events, etc. For example, for the payment module, you need to define interfaces such as online payment, online payment cancellation, payment result query, and public properties such as payment status, payment amount, payment serial number, etc. After the module definition is completed, you need to implement the interface of each module. These implementations should be independent of each other so that they can be tested and replaced individually. For example, the payment module may have many implementation methods according to the actual business, such as WeChat payment, Alipay payment, Cloud QuickPass, etc. Each time a payment method is implemented, we can understand it as adding an optional option to the payment module. As Figure 2 As shown in the figure, after the module is implemented, the system uploads the compiled resources to the server through automated CI and CD, and generates the version number of the implementation module in the corresponding module on the cloud. Cloud operators define different package versions by combining different functional modules according to different module implementations for different customer groups, different customer demands, and different user scenarios. Each package version has a build.config file, which defines the modules that the current package depends on and the module arrangement rules.
[0011] like Figure 3 As shown, when the client is started, if it is in the network state, it first calls the client module version check and update interface, synchronizes the build.config configuration of the current package, compares the module version numbers defined in the build.config and local version.config configurations, and determines if there are new modules or the current module has been changed or upgraded. Then, the version upgrade is performed first. After the module plug-in is upgraded, the local version.config configuration is written back to record the local version number of the current module. At this point, the module distribution action is completed, and the client can normally obtain the corresponding module on demand according to the cloud definition.
[0012] like Figure 4 As shown, after all modules are loaded according to the configuration, the module orchestration rules defined in build.config are read and loaded into the scheduling engine. At this time, the user-defined module loading rules are obtained synchronously to filter out the functions that users do not need in the package. The scheduling engine loads the corresponding modules according to the orchestration rules, creates a Unity container and a MEF composite container locally, and uses the Export attribute to mark them as exportable modules. The dependencies between modules are injected using the ImportingConstructor attribute, and the ComposeParts method is used to add the Unity container to the MEF container. At this time, the startup of the modular container has been completed locally.
[0013] like Figure 5 As shown, the caller interacts with the interface container and obtains the corresponding interface reference to call the business function. At the same time, the expansion of business functions is managed. POS is presented in the form of a desktop client, and the UI logic interaction is in the form of MVVM mode, which separates the UI style presentation from the UI functional logic. MVVM technology: MVVM is the abbreviation of Model, View, and ViewModel. The introduction of this mode is to use ViewModel to reduce the coupling between View and Model, or to reduce the coupling between interface and logic. Ideally, the interface and logic are completely separated. When the interface is changed unilaterally, there is no need to change the logic code. Similarly, when the logic code is changed, there is no need to change the interface.
[0014] like Figure 6 As shown, the steps to implement modular UI interaction are as follows: 2.1. Define plugin interface and base class First, you need to define an interface or base class to define the common properties and methods of the UI plug-in, such as Initialize (initialize UI elements) and Shutdown (clear UI elements). These methods will be called when loading or unloading the plug-in.
[0015] 2.2. Implement UI plugin class Next, implement one or more UI plug-in classes that implement the plug-in interface or inherit the base class and implement custom UI elements. These UI plug-in classes should be exported to the MEF container so that the application can load them dynamically.
[0016] 2.3. Loading plugins Then, create a MEF container and use the composition capabilities of MEF to obtain the exported plug-in. You can use a DirectoryCatalog to specify the directory that contains the plug-in assemblies, or an AssemblyCatalog to specify the assembly that contains the plug-in.
[0017] 2.4. Initialize UI elements When loading the plug-in, you need to use the exported plug-in in the MEF container and call their Initialize method to initialize the UI elements. At this point, you can add UI elements to the main UI control or create child controls in the UI control.
[0018] 2.5. Uninstall plugin When you need to uninstall a UI plugin, you need to call the plugin's Shutdown method and delete the UI element from the main UI control or UI controls. At this point, you also need to remove the uninstalled plugin from the MEF container.
[0019] Therefore, the present invention provides a component modularization method based on MEF and Unity, comprising the following steps: Step 1, defining a module according to predetermined attributes, and then forming multiple interfaces of the module according to the definition; Step 2, uploading the compiled resources to the server and generating a version number of the module in the corresponding module on the server; Step 3, combining multiple modules as needed to form a desired package version with a build.config file, wherein the build.config file defines the modules and arrangement rules on which the current package depends.
[0020] Preferably, step 4 is also included, when starting the client, synchronizing the build.config configuration, comparing the build.config configuration with the module version number in the local version.config configuration, and upgrading and updating accordingly, and writing the corresponding content into the local version.config.
[0021] Preferably, the predetermined attributes include methods, properties and events of the module.
[0022] Preferably, after all modules are loaded according to the configuration, the orchestration rules in build.config are read and loaded into the scheduling engine, the scheduling engine loads the corresponding modules according to the orchestration rules, creates a Unity container and a MEF composite container locally, and marks them as exportable modules using the Export attribute, injects dependencies between modules using the ImportingConstructor attribute, and adds the Unity container to the MEF container using the ComposeParts method.
Claims
1. A component modularization method based on MEF and Unity, characterized in that: The steps include: Step 1, defining a module according to predetermined attributes, and then forming multiple interfaces of the module according to the definition; Step 2, uploading the compiled resources to the server and generating a version number of the module in the corresponding module on the server; Step 3, combining multiple modules as needed to form a desired package version with a build.config file, wherein the build.config file defines the modules and arrangement rules on which the current package depends.
2. The component modularization method based on MEF and Unity according to claim 1, characterized in that: It also includes step 4, when starting the client, synchronizing the build.config configuration, comparing the build.config configuration with the module version number in the local version.config configuration, and upgrading and updating it accordingly, and writing the corresponding content into the local version.config.
3. The component modularization method based on MEF and Unity according to claim 2, characterized in that: The predetermined attributes include methods, properties and events of the module.
4. The component modularization method based on MEF and Unity according to claim 2, characterized in that: After all modules are loaded according to the configuration, the orchestration rules in build.config are read and loaded into the scheduling engine. The scheduling engine loads the corresponding modules according to the orchestration rules, creates a Unity container and a MEF composite container locally, and uses the Export attribute to mark them as exportable modules. The dependencies between modules are injected using the ImportingConstructor attribute, and the Unity container is added to the MEF container using the ComposeParts method.