Visual C # practical makeup of plug-in architecture

In the process of software development, the design process is often much harder than the process of writing code. Therefore, in addition to software testing, the most time-consuming model is system modeling. A good software system should have high stability (reliability), ease of operation and scalability support, especially scalability. In my opinion, good scalability support is a necessary condition for a software team to become active in development. For an application, we hope that we can solve the problem with the least time and manpower when users increase their demands. When others are too busy to meet the rapidly growing needs of users (users cannot tell you the entire requirement during the first requirement analysis), and you, your team only needs to do a little work to satisfy "greedy" users, which improves efficiency and gives the team more time to create, instead of making unnecessary changes.

Unfortunately, I did not take this into consideration in the article "Practice of C # Plug-in architecture. Of course, for a young 18-year-old man without or without team experience, such a mistake (a mistake is a failure-the teacher said) yes ). However, I decided to refactor the plug-in system.

Considering the complexity of the system, I am going to use UML this time (I started learning it last month, but I am not doing well, so I am smiling ).

1. Start Analysis

I am clear about the advice of jan, a netizen, but my thinking is too different. I cannot guarantee that my understanding fully complies with jan's meaning. However, I will still build an application framework model based on my own understanding of scalability.

Go straight to the question. I now assume that I belong to a software team (just call her AbstractSoft for the time being) and serve as a system analyst. Everything has its own normative aspect. We hope that all applications deployed on the same platform produced by our team have the same framework and the same deployment form. In this way, you can form a unique team and win in the competition with efficiency. Because we don't need to design different frameworks for each set of applications-this can save a lot of time!

In this way, I need to separate the program implementation from the user interface into different frameworks. I mean:

In this way, abstract interfaces and some general details exist in the core library of Application Frame Level. The content was deployed on the user's machine when the team was installed for the first time. It will not be destroyed automatically until the user submits a request to remove it from the local device. GUI Level provides unified interface components (for example, Attribute Editor, database operation interface, and other reusable components) after the team's products are generalized ). Speciallized Application achieves scalability by implementing some interfaces in the Application Frame Level, and implements the user interface by using classes in the GUI Level.

The following is a simple static graph (the interface and class members will be described in detail below ):




2. IConnectableObject

Public interface IConnectable { // Application is the main framework object to which the plug-in belongs. If it is null, the plug-in itself is the main framework. ConnectionResult Connect (object application ); ExtendibleVersionInfo VersionInfo {get ;} Void OnDestory (); Void OnLoad (); Void Run (); } Public enum ConnectionResult { Connection_Success, Connection_Failed } Public class ExtendibleVersionInfo { Private ExtendibleVersionInfo (){} Public ExtendibleVersionInfo (string name, string version, string copyright) {// Omitted} Public ExtendibleVersionInfo (string name, int version1, int version2, int version3, string copyright) {// Omitted} Public int PrimaryVersion {get {return _ Version1 ;}} Public int SecondaryVersion {get {return _ Version2 ;}} Public int BuildVersion {get {return _ Version3 ;}} Public string Name {get {return _ Name ;}} Public string VersionString {get {// Omitted }} Public string Copyright {get {return _ Copyright ;}} Private string _ Name; Private int _ Version1 = 1; Private int _ Version2 = 0; Private int _ Version3 = 0; Private string _ Copyright; Public static ExtendibleVersionInfo Empty = new ExtendibleVersionInfo (); }

All connectable objects must implement this interface. This is the first class in all Application Frame levels.

3. IExtendible

Public interface IExtendible { IConnectable GetLatestVersion (); IConnectable QuerySpecifiedVersion (ExtendibleVersionInfo version ); ExtendibleVersionInfo [] EnumerateVersions (); }

4. Use a class factory to create the latest version of applications and plug-ins

Our main program and plug-in will be designed as an internal class. The program outputs only one factory class. On the user interface, you can call the GetLatestVersion () method of the IExtendible interface to obtain the instances of the objects used to complete the actual task and display them. Alternatively, you can enumerate all versions to select the desired version.

5. scalability

I have to admit that this method is not very scalable. When the program needs to be upgraded, it also needs to modify the factory class provided to the user (although the interface remains unchanged ). To achieve better scalability, you can convert the simple factory mode to the factory method mode.