Design of plug-in GIS framework

Three years ago, I bought a GIS plug-in framework book from Jiang potao, as recommended by my senior brother. At that time, while reading a book, I made a complete implementation of the examples, which benefited a lot. Later, a plug-in C/S system was developed for the project, using the MEF framework provided by Microsoft. In this system, communication between plug-ins and plug-ins not involved in Jiang potao's book has been completed. However, Jiang potao's book involves a lot of underlying content of the plug-in system. The design of the plug-in engine is particularly worth learning. Recently, I have summarized my example and shared it with you.

1. Plug-in framework composition

(1). The framework is divided into two parts: Host Program and plug-in object.

(2). Two-part interaction is based on a public communication contract

(3) The host program can exist independently.

2. Reasons for using the plug-in

(1). extend the functions of the program without re-Compiling and publishing the program.

(2). New functions can be added to the program without the need for source code.

(3) flexible adaptation to the changing business logic of a program and frequent addition of new rules

3. General Implementation Technology of plug-ins

(1). Plug-In Based on Dynamic Link Library DLL

(2). com-based plug-ins

(3) Reflection-based plug-ins

4. elaborate on the implementation of this framework. 4. 1. design all and implement some interfaces.

Interfaces are divided:

Host interface: iapplicaiton

Plug-in Interface: iplugin (icommand, itool, imenudef, itoolbardef, idockablewindowdef) and iitemdef not inherited from ipluging

In this chapter, the application inherited from iapplication and the itemdef class inherited from itemdef are implemented. The class diagram is as follows:

 

 

 

 

 

4.2 create a plug-in Container

When the instantiated plug-ins are not added to the host, a host hosting these instantiated plug-ins is required.

Therefore, we have to design a plug-in container after designing the plug-in interface. This container can only store classes inherited from iplugin.

4.2.1 design plugincollection

First:

Inherits the abstract class collectionbase.

Collectionbase has implemented three interfaces, including ilist, icolloction, and ienumerable, to solve most of the problems.

(The main focus is to overwrite a new getenumerator () method, and this method returns a class that implements the ienumerator interface. if yield has been used to implement the iteration function when rewriting this method, you can skip the Second Step ).

Then:

Write the class that inherits and implements the ienumerator interface. (Rewrite the current, movenext, and reset functions)

4.3 design the reflection mechanism in pluginengine

We have designed communication interfaces and interface containers. Why can't a plug-in be identified only when one of these interfaces is implemented?

Because our interface engine can only identify these interfaces.

What is an interface engine?

To put it simply, in this system, the interfaces of each type obtained after reflection must be the interfaces defined above before they can be recognized and responded.

 

4.3.1 detailed dynamic loading and object generation

Reflection mechanism is the core technology of our plug-in system.

It enables these classes to be dynamically loaded and called.

(1) the system first uses the directory. getfiles () function to obtain all DLL files in the target folder.

(2). Use the reflection function assemly. loadfrom to load the file (several assemblies are obtained ). Use gettypes () of the Assembly to obtain the type [] array.

(3) Finally, use getinterfaces () of the type class to obtain the interface inherited by each class. Use switch to check whether the class inherits the custom interfaces. If so, use the activator. createinstance (Type _ type) method to instantiate this class. Add it to the plug-in container plugincollection.

 

4.4 plugin Classification

Set five interface dictionary containers, including icommand, itool, itoolbardef, imenudef, five containers of idockablewindowdef and one command-type container (which will store non-repeated category that implements icommand and itool ).

Note: The key values in these containers are the names of the plug-ins that implement these interfaces.

 

4.5 establish a host framework

Use the third-party control Janus winforms controls v3.5 to design the interface.

The third-party control has two controls: uicommandmanager and uipanelmanager, which are helpful for plug-in insertion and display.

 

When this host is instantiated, an apllication class is first instantiated, and then an important attribute value is assigned to mapcontrol, pagecontrol, and mainplantform in this instance.

Therefore, the interaction between the host and the plug-in is not difficult to implement through the copied instance.

4.6 plugin acquisition

This is a big aspect and also the core. That is, how can we make the host get the plug-ins that are still in the plug-in container and can be displayed in the host?

1. Because command and tool are of the same type on the UI, they are obtained together.

There are two points to note: one is to make the instance create (Hook), that is, to pass the relevant information class application of the host. The second is to register a system-defined event. For example, uicommand + = new commandeventhandler (uicommand_click );

2. Similarly, you can obtain the objects that inherit imenudef, itoolbardef, and idockablewindowdef.

Note: floating forms are hosted by uipanelmanager. That is, add the childhwnd (control class) in the floating box to panelcontainer. Controls in the new panel.

4.7 event handling of plug-in objects

In the previous step, we registered an undefined event handling method to the click event through the built-in delegate.

In this section, we will write the event processing method in detail. Command is interactive, and tool is not interactive. So there is a big difference in writing.

The two processing functions share two key points: one is to use E. Command. Key of E (commandeventargs class) to obtain the objects placed in the relevant plug-in dictionary container. The second is to trigger the click function of the object.

4.8 framework plug-in Design

 

This section is where the system can be expanded in the future.

Here we focus on the implementation of the cadddata plug-in.

This class first inherits the icommand interface. In the CREATE (iapplication hook) method triggered by loading the host form to obtain various plug-ins, call the controlsadddatacommandclass () class that comes with engine, and hook it to the mapcontrol of the passed host.

 

4.9 advanced design of the Host Program

You can perform some advanced design on the host program itself. For example, mapcontrol and pagecontrol are displayed in association. For example, you can define a floating menu of toccontrol or query and display of development element data.

Note: These designs are designed for the host itself and have nothing to do with the plug-in. Is to maximize the use of the host form itself.

4.10 framework auxiliary component framework Library Design

This section is designed for a more convenient development framework or its plug-in itself.

In this section, you can write and encapsulate many methods that may be used in the future, and then call them directly after development.

This part can be called the system development kit (SDK), but this part is not necessary.

4.11 system release

When releasing a system, you must first determine which basic platforms are required to run the system on an empty machine.

When the system is running, at least the. NET 3.0 framework redistributable package, Janus system UI v3.5, and ArcGIS engine10 Runtime

Then, use InstallShield express X to package.

5. Result Display

 

6. Advantages and disadvantages of this framework and its prospect: 6.1 advantages

This framework is purely developed at the underlying layer, with good portability and versatility. It has other characteristics of General plug-ins, such as scalability and decoupling. In line with the programming philosophy of interface-oriented and dependency inversion, this framework also integrates the command mode, observer mode, traversal mode, appearance mode, and Singleton mode.

6.2 weaknesses

The granularity of this framework is too small, which can easily lead to explosive growth of classes.

This framework only implements communication between the plug-in and the host, but does not implement communication between the plug-in and the plug-in.

6.3 Outlook

To resolve the communication between a plug-in and a plug-in, you can create a separate plug-in for complex communication. Other plug-ins reference this plug-in. With the observer mode, after loading the plug-in the host, you can implement event registration and communication between plug-ins.

At the same time, many frameworks have implemented plug-in programming ideas. Billy uses spring dependency injection and all the MEF dependency injection provided by Microsoft to implement the plug-in system.