[框架设计之道（二）]设备、任务设置及业务流程

对于配置文件管理模块，我不希望提供过多和过花哨的接口。事实上，各式各样的配置文件管理模块实际上就是修改某个设备下的某个json文件。一个ConfigHelper需要包括多个设备，当然了，它实际上是以文件夹为单位进行管理的

每一个设备应该都会有一个init.json和一个DeviceParams.json文件，所以他们是以一个文件夹的形式保存起来的。

如图所示：

以这样的文件夹形式存放各个设备的参数信息，所有的信息都是以本地文件的形式存放的，所有的文件都需要热取用，因为随时可能会发生中途设备信息修改等等，所以再接口getConfigContain中，需要每次打开文件进行读取，而不是提前读取好了放在本地。
2.基本流程
配置文件管理模块流程大致如下：

读取和写入都需要保证可以在热读取下操作。否则每次重新设置或者配置文件可能都需要重新启动软件，会非常不灵活。

其中所有的设置和读取配置文件，只涉及两个功能，也就是所谓的写入和读取文件，仅此而已。

二、任务设置
任务设置模块应该是在主程序的kernel中进行的，每次在gui进行一次配置的时候都需要在主程序的kernel中
1.任务设置
每次任务设置参数涉及很多个方面，但主要的参数包含以下几个方面

1>任务的基本信息：名称、备注
2>需要换算的信息：隧道直径、小车速度、相机曝光时间、图片重复率

实际上，一个任务就只有两个信息是需要主动包含的，一个是基本信息，一个是换算信息。这里我们暂且不聊换算信息。为什么呢，因为这个是需要和后续的设备信息进行联动的，这里的所有基本换算都是来自gui程序或者主程序中本地的换算，所以轮不到设备的控制层去关系。

所以对于控制层来说，唯一需要关心的就是文件存储的路径，以及配置文件存放的路径。

三、业务流程
我们在所有设备的控制层代码中都写好了一套配置流程，那自然在主程序中也得有一套完整的流程。一套完整的流程控制不仅可以使在具体的采集过程中的程序更加可靠，也可以使得面对各种异常情况下能够更加优雅。另外值得一提的是，需要将错误日志系统搭建完善，而不是之前那一套没人看得懂的错误日志。

业务中，我们需要让每一次作业保持以下流程：

我需要简单解释一下此图：在全流程中，GUI只是一个人机交互的接口，也就是说GUI并不参与到具体的业务中，也不会做任何计算和任何的业务流程。

所有，注意，是所有的任务，都可以在主程序中完成，即使主程序在开发的过程中并没有提供GUI，只凭借仅有的控制台也应该要能够完成整个采集任务。

其中，设置设备信息和设置任务信息都不是必须的，这里需要提供两套预设，一套是存放在本地文件的default.json文件，另一套是放在代码内部的，基于目前已有的设备执行。

但是这里有问题，值得注意的一点是，扫描仪的并不是提前可以通过扫描获得的，而是只能通过提前设定好ip、sn和key来尝试连接的，所以扫描仪设备和所有的设备都不一样，需要在跳过设备信息之前提前确定扫描仪的信息。

开始采集、暂停采集、停止采集在主程序中比较好获取，因为在控制层中就已经对所有状态做好了声明和控制，只需要按照流程来即可。

最后，停止采集一定是所有控制中级别最高的，不论当前是任何状态，只要发送了停止采集的命令，机器就必须马上停止运转，状态归零，这是很重要的一点。