Build a plug-in Application Framework (II)-contract formation

Whether it is used Com Is normal DLL , Or . Net To implement the plug-in framework, the first problem is how to establish a contract. As in my previous articleArticleAs mentioned above, a contract is an application.ProgramThe Basis and credential for interaction with the plug-in. The application must declare what features can be used by the plug-in and what conditions must be met by the plug-in before it can be used by me. On the other hand, the plug-in must know the features provided by the application so that I can integrate my functions into the application system. This series of articles focuses on how to use . Net Implement plug-in application frameworks, so I will not mention other methods.

How to Use. NetWhat about a contract? First thoughtInterfaceThe second is the abstract class, but I use interfaces in the plug-in mode, because we provide additional plug-in functions based on the main purpose of the application. In this regard, interfaces are more flexible and easier to expand. Next, how should we conclude the contract content? This depends on your business needs. For ease of explanation, we define a plug-in contract for the most basic plug-in applications. Let's make a hypothesis that our application is a multi-document application that contains a main menu bar, a toolbar. The menu bar can be docked in the upper, lower, and left directions of the program, and a status bar. Later, if necessary, I will extend this application so that it can provide more functions for the plug-in. So for now, the function I want to implement is to allow the plug-in to add a toolbar for the main program, menu items and implement some simple functions.

An application provides services to the plug-in two ways. One is to directly declare attributes or methods in the application interface, and the other is to declare the application interface as a service container. I plan to use both methods. Explicit functions are directly declared as attributes or methods in interfaces, and applications are declared as a service container to facilitate the insertion of more service functions, improve the scalability of applications.

Below is a very simple application interface definition, which is sufficient for our assumptions.

Using System;
Using System. Collections. Generic;
Using System. text;
Using System. componentmodel. design;
Using System. Windows. forms;

Namespace Pluginframework
{
Public   Interface Iapplication: iservicecontainer
{
Toolstrippanel lefttoolpanel {Get;}
Toolstrippanel righttoolpanel {Get;}
Toolstrippanel toptoolpanel {Get;}
Toolstrippanel bottomtoolpanel {Get;}

Menustrip mainmenustrip {Get;}
Statusstrip statusbar {Get;}
}
}

Plug-in Interface Definition:

Using System;
Using System. Collections. Generic;
Using System. text;

Namespace Pluginframework
{
Public   Interface Iplugin
{
Iapplication {Get;Set;}
String name {Get;Set;}
String description {Get;Set;}
Void Load ();
Void Unload ();

Event Eventhandler < Eventargs > Loading;
}
}

It's not too early. I will write it here today, and I will write it tomorrow.