[Serialization] Design and Implementation of the C # communication (Serial Port and network) framework-7. Design of external interfaces,
Contents
Chapter 7 Design of external interfaces... 2
7.1 plug-in interface... 2
7.2 graphic display interface... 3
7.3 data export interface... 5
7.4 service component interface... 6
7.5 plug-in manager... 8
7.6 framework integration and restructuring... 9
7.7 Summary... 10
Chapter 7 Design of External Interfaces
Developers can not only develop device drivers twice, but also develop custom image display formats,
Custom Data export formats and a variety of business services, and the device driver interface and these three interfaces for Event Response and data interaction.
7.1 plug-in Interface
The graphic display interface, data export interface, and service component interface all inherit from the unified plug-in Interface (IPlugins), which is mainly for convenient management and expansion. The code of the plug-in interface is defined as follows:
Public interface IPlugins: IDisposable {// <summary> // service Key, which must be unique // </summary> string ThisKey {get ;} /// <summary> /// service name /// </summary> string ThisName {get;} /// <summary> // Update device data, used to receive data from the device driver /// </summary> /// <param name = "devid"> device ID </param> /// <param name =" obj "> device object </param> void UpdateDevice (int devid, object obj); // <summary> // remove a device and respond when the Framework Platform deletes the device. /// </Summary> /// <param name = "devid"> device ID </param> void RemoveDevice (int devid );}
The inheritance Relationships Between Graphic Display Interfaces, data export interfaces, and service component interfaces and plug-in interfaces are as follows:
The device driver transmits data to the UpdateDevice interface through events as long as there is updated data. The second developer decides how to process the interface internally. When a device driver deletion event is triggered, the RemoveDevice interface is called to delete or release resources.
7.2 graphic display interface
The communication device driver of the Framework Platform only collects raw data. After processing, business data must be formed, and business functions such as display, analysis, query, printing, and report will be available, for the same data information, different user requirements vary greatly. This part of the function changes a lot, but it is not necessary to modify the Framework Platform every time there is a change, because the framework is a "stable" part, and it will not be changed after the version control is formed.
Based on this consideration, the framework should provide a mechanism to load the UI forms designed by secondary developers. This interface is used to display the data of Collection Terminal devices. Data of different types of devices can be integrated and displayed on different interfaces in multiple forms. It is convenient to provide users with a variety of user-friendly Human-Computer Interaction interfaces.
First, the Framework Platform cannot display all UI forms at startup. The user determines which UI form to display, we need to load the component information of the secondary development to the menu in the form of a configuration file to provide a trigger display event entry, such:
Secondly, what form is displayed? Like many management systems, we use Form Tab display, such:
Public interface IGraphicsShow: IPlugins {// <summary> // when the form event is closed /// </summary> event GraphicsShowClosedHandler; /// <summary> /// right-click /// </summary> event MouseRightContextMenuHandler ;}7.3 data export interface
In a data integration system project, either the device data of another manufacturer is integrated or the device data of another manufacturer is integrated into the home. Without a unified standard, there are various formats of integrated data. To meet this scenario, a special interface is designed for the device to export data. developers can inherit this interface. After the device completes data processing, the data is automatically transmitted to this interface, you can output data in the specified data format.
Real-time data export of device drivers allows you to export a type of device data into multiple data formats.
The export data plug-in can be loaded through the configuration file. As long as the device driver has data updates, the data is transmitted to the export data interface through events. If you do not configure the plug-in information in the configuration file, the program does not load or export the information. Therefore, this transactional service does not need to be completed through the interface and can be completed through code when the host program starts.
The IExportData export interface code is defined as follows:
Public interface IExportData: IPlugins {// <summary> // format the data /// </summary> /// <param name = "devid"> </param> // <param name = "obj"> </param> // <returns> </returns> object FormatDataString (int devid, object obj, DeviceType devicetype );}7.4 service component interface
The data collected by the device driver module can provide a variety of application services based on the application field and needs, for example: data Forwarding Service, 4-20mA service, SMS service, LED service, OPC service, and complex Real-time Data Analysis Service. To ensure real-time and stable data, service interfaces can provide a unified service mechanism for developers to perform secondary development.
The service method of service plug-ins. This service is a transaction task that runs for a long time, so it is more complicated.
Some services need to run automatically as the host program starts, and some services need to be manually started to run. When the host program starts, the service information needs to be loaded to the menu through the preparation file. Some services displayed in the menu may have been started, and some services need to be clicked, display the form and enter necessary information before it can be started. Therefore, host programs and service plug-ins are not unidirectional interaction, but bidirectional data and event interaction.
The IappService service interface is extended based on IPlugins. Functions, attributes, and events are added. The Code definition is as follows:
Public interface IAppService: IPlugins {// <summary> // start the service /// </summary> void StartService (); /// <summary> /// whether to automatically start /// </summary> bool IsAutoStart {set; get ;} /// <summary> /// service type /// </summary> ServiceType {set; get ;}/// <summary> /// click the event, association menu /// </summary> void OnClick (); // <summary> // release the service /// </summary> void ReleaseService (); /// <summary> /// write log event /// </summary> event WriteLogHandler ;}
(1) StartService function: When the Service Startup method (IsAutoStart) is "auto start", the Framework Platform automatically calls this interface function when loading the service, start the service.
(2) IsAutoStart attribute: indicates the Service Startup type. It indicates whether the service is automatically started as the Framework Platform starts, that is, whether the StartService interface function is called.
(3) ServiceType attribute: service types include: Display Mode and hidden mode. The service in display mode loads the service name identified by ThisName on the Framework Platform menu. The hidden mode does not load the service name in the Framework Platform menu, you can set the IsAutoStart attribute of this type of service to auto start. The Framework Platform automatically starts the service after it starts. The code is defined as follows:
Public enum ServiceType {[EnumDescription ("display mode")] Show = 0x00, [EnumDescription ("Hide mode")] Hide = 0x01}
(4) OnClick event function: when the service type ServiceType is set to "display mode", the service name is loaded into the menu. When you click the service menu item, the OnClick interface function of the corresponding service is called. You can call the form in this interface function.
(5) ReleaseService function: You can use this function to release service resources after you disable the Framework Platform and manually stop the service.
In addition, the Service component interface also involves the service status, which identifies the service in the running process
Stage, such as starting a service, starting a service, running a service, terminating a service, and terminating a service. The service status may vary depending on the transaction complexity of the service. Therefore, the service status is defined by the secondary developer.
7.5 plug-in Manager
The graphic display interface, data export interface, and service component interface each have an interface manager responsible for managing each functional interface. They all inherit from the IBaseManager <TKey, TValue> interface. The inheritance relationship diagram is as follows:
In fact, the modules that inherit the four interfaces for secondary development are loaded to the Framework Platform in the form of plug-ins. The Framework Platform implements a complete set of operating mechanisms in the structure. The above inheritance relationship structure diagram is analyzed, and there is still room for integration and reconstruction, further clarifying the interface relationship, integrating code, and improving the scalability of the framework. The interface inheritance relationship after reconstruction is planned, for example:
All extensible interfaces inherit from one plug-in interface, and then branch out other business function interfaces, similar to all objects in C # Language inherited from objects.
Conclusion 7.7
In fact, the Framework calls the interface directly, and the coordination between the interface and the interface implements a coordination mechanism, thus gradually implementing a framework platform. As an interface, it is actually a form of implementing the connection between the secondary development and the Framework Platform, and ensuring that specific business functions are implemented in the coordination mechanism of the Framework Platform. Therefore, any framework is designed for interfaces from the top layer.
Author: Wei Xiaozhi
Mail: 504547114@qq.com
QQ: 504547114
. NET Development Technology Alliance: 54256083
Document Download: http://pan.baidu.com/s/1pJ7lZWf
Http://www.bmpj.net