C#框架的总体设计知识点有哪些

本文介绍了关于“C#框架的一般设计知识点是什么”的知识。很多人在实际案例的操作中会遇到这样的困难。接下来，让边肖带领大家学习如何应对这些情况！希望大家认真阅读，学点东西！

2.1 宿主程序设计

作为一个插件应用框架，应该有一个宿主程序来承载和加载插件，为插件和驱动提供一个可运行的环境，使宿主程序和插件无缝对接。宿主程序和插件的关系就是水和鱼的关系。有水无鱼，水就失去了价值。如果有鱼没有水，鱼就会死。从关系的角度来看，开发框架的目的是什么？它与其他事物相关，包括开发人员、二级开发人员、用户、插件，甚至其他软件或组件。发生的关系越多，相处越融洽，这证明了这个框架的价值越高。所以一个好的框架平台不仅体现了开发者的技术，也体现了开发者的情商。

SuperIO框架使用NET反射技术开发插件管理机制。本章不详细介绍具体技术细节，《第8章 插件引擎设计》详细介绍技术应用。

那么一个框架的宿主程序应该如何设计呢？或者从哪些方面考虑设计问题？在开发SuperIO框架的时候，我一直在思考这个问题。首先，这个问题不应该从技术的角度去考虑，而应该从人的角度、用户的角度和二级开发者的角度去考虑，去规划宿主程序。

从应用来看，主机程序应该包括：用户管理、设备驱动管理、设备状态监控模式、用户自定义UI插件显示模式、用户自定义输出数据插件运行模式、服务插件服务模式、软件运行监控模式、串口IO通道监控模式、网络IO通道监控模式等等。这些都是从大方向规划的，需要进一步细化来指导我们的发展工作。

用户管理，支持多用户和用户权限分配。对于实时数据采集框架来说，面对现场应用时，肯定会涉及到两个角色：用户和工程师。面向用户的权限：可以查看参数和数据信息。工程师权限定位：不仅拥有用户权限，还可以修改参数。用户管理的菜单，如下所示：

设备驱动管理，设备驱动(插件)是通过接口和抽象类设计的框架核心部分之一，可以将新开发的设备插件加载到框架中运行，完成数据采集、验证、分析、处理等相关操作，并与命令和数据进行交互。同时设备驱动管理也要具体删除相关设备插件的功能。添加设备插件，如下所示：

设备状态监测方法，我们可以称之为“设备操作员”。它不是简单地显示不同类型设备驱动程序的所有参数和属性，而是显示和监控设备的一般参数、属性和实时状态，如设备ID、设备名称、地址、通信类型、IO参数、IO状态、通信状态、设备状态、报警状态、设备类型和编号等。下图：

自定义UI插件显示模式，二级开发人员在标准化界面的基础上开发数据显示模式，并挂载到框架的配置文件中。当用户点击一个显示视图时，它以Tab窗体的形式显示，点击按钮即可关闭，如下图所示：

自定义输出数据插件的操作模式。这种输出数据是实时数据的导出，更多的是一种事务性服务，可以将一种设备数据输出成多种数据格式。输出数据插件可以通过配置文件加载。只要设备驱动有数据更新，数据就会通过接口传输到输出数据插件进行输出操作。如果在配置文件中没有配置插件信息，将不会加载或输出程序。因此，这种事务服务不需要接口来完成，而是可以在宿主程序启动时通过代码来完成。

服务插件的服务模式是一个长期运行的事务性任务，更加复杂。有些服务需要在主机程序启动时自动运行，有些服务需要手动启动才能运行。当主机程序启动时，需要将服务信息加载到菜单中。菜单中显示的一些服务可能已经启动，其中一些服务可能只有在单击操作、显示表单并填写必要信息后才能启动。因此，宿主程序和服务插件不是单向交互，而是双向数据和事件交互。例如，在收集和处理设备的数据后，要将数据上传到服务中心或其他区域，只需

可以开发一个插件来完成这项任务，如下图：

     软件运行的监视方式，这是一种实时日志监视器，可以监视框架运行情况、以及设备的运行情况。把异常的信息可以友好的显示出来，把异常的详细信息保存到日志文件。我们可以把它称为“运行监测器”，对于实时数据采集框架的运行是很有帮助的。如下图：

     串口IO通道监视方式，当某一个设备驱动以串口方式通讯时，当串口参数动态发生改变时会在串口监视器反映当前串口IO状态，例如：增加串口、删除串口、串口号和波特率的改变等。如下图：

     网络IO通道监视方式，相对好设计一些，只需要对Socket实例的连接和断开进行事件反映，Socket实例有效时把信息增加到网络监视器中，Socket实例无效时，并释放了相关资源后，从网络监视器删除相关信息。如下图：

      基于以上的分析，我们需要构建一个完整的宿主程序，必要的功能要有，但是这个程序不一定很复杂，因为有些功能、响应、属性、数据等可以放到设备插件中完成，在《第3章   设备驱动的设计》中详细介绍设计情况。构建的宿主程序，如下图：

     如果光有了宿主程序，那么还没有分析全面。还需要以二次开发者的角度分析宿主程序是否能够与二次开发者保持良好的关系。这里涉及到宿主程序存在的形式问题，宿主程序作为SuperIO框架的一部分，是一个整体的组件。希望二次开发者继承宿主程序就可以快速构建一个自己的主程序，可以在此基础上扩展功能，这样的话，需要把宿主程序的关键控件的访问权限设置成protected。另外，宿主程序还需要一个配置文件，把二次开发者关心的参数可设置，例如：标题、版本号、公司名称等。

    经过上述的过程，我们就对宿主程序有一个清晰认识和规划。界面的骨架已经搭建出来，在后期的开发过程序中从细节着手，逐步实现这些功能。但是，这样一个简单的界面需要很多类、模块等支撑。以后章节会对每个模块进行详细设计说明。                                

2.2    通讯机制设计

    对于实时数据采集框架，通讯部分始终是软件的核心，要求高实时性、高稳定性。软件框架决定了软件运行的稳定性，以及以后的扩展性，所以需要对通讯机制、控制方式进行良好的设计。

    在《1.通讯框架介绍》中的已经对应用场景进行了介绍，所以决定了软件框架在通讯方面的应用有两种方式：主动请求和被动接收。

    主动请求方式又可以称之为呼叫应答方式或主从方式。也就是说，主动权在软件框架端，只有软件框架主动发送请求命令，从机（硬件设备、传感器等）接收到命令后并且检验数据的完整性，以及确定是否发给自己的命令，校验成功后，返回指定的数据信息，完成一次完整的链路通讯过程。呼叫应答通讯方式，如下图：

   被动接收方式是软件框架实时监测IO通道，只要有数据信息就会提取出来，进行数据校验，检验成功后，分析、处理、保存数据信息。例如设备、传感器等定时发送状态数据。这种通讯方式，如下图：

    在复杂的应用场景中，这两种通讯方式都有可能存在，此类情况一般是采用以太网链路进行通讯。针对只有外接串口的设备可以通过以太网转换模块来接入。

2.1.1    串口通讯机制

由于串口通讯的特性限制，避免多个硬件设备连接到串口总线出现数据混乱

现象，一般采用轮询模式的呼叫应答通讯机制。

2.1.1.1     轮询模式

当有多个设备连接到通讯平台时，通讯平台会轮询调度设备进行通讯任务。某一时刻只能有一个设备发送请求命令、等待接收返回数据，这个设备完成发送、接收（如果遇到超时情况，则自动返回）后，下一个设备才进行通讯任务，依次轮询设备。如下图：

2.2.2    网络通讯机制

   轮询通讯机制是保证数据有序的发送、接收，避免并发数据在串口总线上出现混乱，但是这种通讯机制是以降低性能为代价的，适用于串口通讯，在以太网通讯中显然无法充分利用网络通讯的优势。以太网是独立信道、可以全双工通讯。为了充分发挥以太网的优势，在轮询通讯机制的基础上增加了并发通讯模式、自控通讯模式。一是为了提高通讯的性能，二是为了二次开发有更多自主控制权。

2.2.2.1     轮询模式

   以太网轮询通讯模式与串口通讯模式一致，如下图：

2.2.2.2    并发模式

     并发通讯模式是集中发送所有设备的请求指令，现在SuperIO框架是采用循环同步方式发送请求命令。还有进一步提高的机会，采用并行异步方式集中发送请求命令。硬件设备接收到指令后进行校验，校验成功后返回对应指令的数据，通讯平台异步监听到数据信息后，进行接收操作，然后再进行数据的分发、处理等。如下图：

2.2.2.3    自控模式

     自控通讯模式与并发通讯模式类似，区别在于发送指令操作交给设备驱动本身进行控制，或者说交给二次开发者，二次开发者可以通过时钟定时用事件驱动的方式发送指令数据。硬件设备接收到指令后进行校验，校验成功后返回对应指令的数据，通讯平台异步监听到数据信息后，进行接收操作，然后再进行数据的分发、处理等。

      自控通讯模式可以为二次开发者提供精确的定时请求实时数据机制，使通讯机制更灵活、自主。如下图：

      并发模式和自控模式都可被动接收数据，应用场景更加灵活，使软件框架和硬件设备的开发过工作更自由。

2.3   层次示意图

2.4    模型对象示意图

“C#框架的总体设计知识点有哪些”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！