Enterprise-level agile software development platform agileeas. Net-plug-in interface imodule Based on DOTNET Component Technology

We know that to develop based on the platform (container) + plug-in mode, we must define a set of contracts to constrain module plug-in development, that is, the module plug-in must comply with certain standards for development before it can be normally called by containers. This is what the imodule defines.

 Imodule  /// <Summary>  /// Define the basic specifications of the EAS module plug-in.  /// </Summary>  Public   Interface Imodule: iobject { /// <Summary>      /// Obtain the module name.      /// </Summary>      String Modulename { Get ;}/// <Summary>      /// Obtain the description of the module.      /// </Summary>      String Moduledescription { Get ;} /// <Summary>      /// Obtain the group information of the module.      /// </Summary>      String Group { Get ;} /// <Summary>      /// Triggered when the function module is successfully started.      /// </Summary>      Event System. eventhandler started; /// <Summary>      /// This event is triggered before the module is disabled.      /// </Summary>      Event System. eventhandler exited; /// <Summary>      /// Close the current module. This method is used to closeProgramModule.      /// </Summary>      Void Close (); /// <Summary>      /// Run the current module. This method is used to load the module by the running shell and call the module.      /// </Summary>     /// <Param name = "Parameters"> list of initial parameters for running the module. </Param>      Void Run ( Params   Object [] Parameters );}

The imodule defines the module name, the method run () called by the module, and the events loaded and closed by the platform. From the definition, we can see that the imodule continues to use the iobject interface.

Iobject/// <Summary>/// Define the basic specifications of system objects./// </Summary>Public InterfaceIobject: iprivilegobject, system. idisposable {/// <Summary>/// Obtain the description of the object./// </Summary>StringDescription {Get;}/// <Summary>/// Obtain the object icon./// </Summary>System. Drawing. Image icon {Get;}}
 

Here is why the iobject interface appears. Here is a description, which is EAS. at the beginning of the design of the net platform, we introduced an idea that we collectively refer to the modules, Orm objects, and defined external devices in the program as objects and manage these objects, based on this idea, we introduced the concept of an object. However, in practical application, the understanding of the Object layer is gradually discussed. Maybe in future design, cancel this interface.

The iobject interface explicitly defines the descriptive object descriptions and icons of objects. For the imodule interface and the iobject interface, they all inherit from an important interface iprivilegobject.

 Iprivilegobject  /// <Summary>  /// Basic specifications of system permission objects.  /// </Summary>  Public   Interface Iprivilegobject { /// <Summary>      /// Obtain the guid of the permission object ).      /// </Summary> System. guid {Get ;} /// <Summary>      /// Obtain the type information of the permission object, that is, the Class Name of the object.      /// </Summary>      String Type { Get ;} /// <Summary>      /// Obtain the object permission name.      /// </Summary>      String Name { Get ;} /// <Summary>      /// Obtain the version information of the object.     /// </Summary>      String Version { Get ;} /// <Summary>      /// Obtain the assembly information of the object.      /// </Summary>      String Assembly { Get ;} /// <Summary>      /// Obtain the developer information of the object.      /// </Summary>      String Developer { Get ;}}

Iprivilegobject is the access item of the permission object. The Platform (running container) can use its authentication system to perform permission checks on it. I will elaborate on the system permission design later.

In the module plug-in interface, we see a lot of information about the module self-description, such as name, description, type, assembly, version number, and developer, the purpose of defining this information is to customize the module description. The Resource Management Platform reads the metadata and stores it in the database during the module installation process to facilitate the management of plug-ins in the system.

The Assembly and type information defined in module metadata are used for container reflection call plug-ins. This is also a key technology that Platform + plug-ins depend on.

In specific application development, some extensions and basic implementations of the imodule interface are implemented for different applications of winfrom and webform, which are used for specific applications in the application development process to speed up development.

In the next articleArticle.

Link: agileeas. NET application development platform Introduction