MAF application framework design summary I -- Origin

MAF framework originated from a winform project developed last year. This project implements a simple multi-tab page style main user interface like Visual Studio. All functional modules are developed in the form of usercontrol and integrated into the main user interface as plug-ins. This framework dynamically loads controls and displays them on the Interface Using Reflection (+ configuration file) + class factory methods, and integrates the permission control mechanism, this frees project developers from the tedious coding work of interface integration and permission verification, significantly improving development efficiency.
However, due to my lack of design experience, this framework adopts the white-box multiplexing method to implement-use user controls directly as plug-ins, and design a unified parent control/plug-in class, the control logic includes permission control, editing status, and data access, which leads to the following problems:
1. Poor availability. In addition to reloading some virtual methods, developers also need to understand and use the symbols defined by many basic classes and the meanings and usage of tool methods. Many bugs are caused by forgetting to call a method or setting a flag.
2. The framework is too invasive. Because too many infrastructures are provided by the parent class, subclass controls are highly dependent on the framework. Such controls cannot be developed and tested outside the framework. As the scale of the project expands, compilation-> execution-> tracking becomes slower and slower, while Automated Unit Testing becomes a luxury.
3. poor scalability and maintainability. Because too many things have been done in the same class (as a plug-in control), many bugs have been generated due to the frequent loss of both sides during development. Due to the large granularity of plug-in classes, the consistency of the design scheme is also out of control, resulting in some self-contradictory designs. These details are highly dependent on each other, so it is extremely difficult to modify them. At that time, the project development time was relatively short, so that the framework development could only be performed in parallel with the application, doubling the impact of the problem.
4. the design scheme is incomplete. The control is a plug-in, so the permission division granularity is very simple, the flexibility is poor, it is often necessary Code Install some patches to meet the actual and common permission verification requirements.
At the beginning of this year, I participated in a new project: Porting some of the company's older series of products developed using VB to the. NET platform. According to the O & M requirements of these products, the team needs to provide a unified platform for these products, especially implementing a plug-in architecture to facilitate product deployment, maintenance, and upgrade. This project takes three months.
Similar problems are facing me again. The difference is that, after the development of the project "mine" last year, my mind was somewhat bottomed out. At least, I would not step on mine more than last year ~~
The problems to be solved are summarized as follows:
1. support extension of functions by plug-ins
2. Support for online defect reporting and automatic upgrade
3. concurrent development of frameworks and Applications

(Tupiao carrying tieniu ...)

Note: MAF is a mosaic name, and the real name is no longer available