一般的数据采集winform软件框架

Question

1、做数据采集，需要显示信号文本，信号曲线，保存文本等功能，基本的框架应该是怎么样的。是不是一定要有数据库。
通过数据也可以, 网络SOCKET 也行, 只要能够通信,不丢数据包的都可以
2、数据库的写入与文件的写入有什么区别，是不是也要多硬盘频繁的写
数据库在大批量数据导入有优势文件保存个配置什么的都行
3、在ui更新比较耗时导致不能实时显示的情况下，是不是可以从数据库来读取数据进行文本显示和曲线显示。
可以的

Answer 1

第二个问题，如果是涉及到复杂的数据操作，选择数据库操作会比文件操作更容易实现，因为数据库服务会解析SQL语句，一句简单的SQL语句实现的功能是直接操作文件难以做到的，用数据库保存的数据最终也是保存到数据文件里。楼主是不是做单片机或嵌入式的

Answer 2

1、做数据采集，需要显示信号文本，信号曲线，保存文本等功能，基本的框架应该是怎么样的。是不是一定要有数据库。
首先要明确数据采集的目的.
数据采集如果是为了最终的查询与统计,当然必须有数据库,否则从文件直接筛选数据会很困难.
如果单纯的采集出来,将数据给第三方(比如通过互联网传xml),由第三方入库,你就不需要数据库.
2、数据库的写入与文件的写入有什么区别，是不是也要多硬盘频繁的写
同1,看你数据库放在哪.如果放在本地,当然最终还是以文件形式存储.如果是在其他地方,可能就只需要通信.
3、在ui更新比较耗时导致不能实时显示的情况下，是不是可以从数据库来读取数据进行文本显示和曲线显示。
数据量很大的时候,只显示个当前数据就够了,有任何必要把所有数据都实时显示? 

Answer 3

1、框架没有固定的形式，要看你的需求来定，要不要数据库取决于你将来是否需要进行历史数据的查询和具体的查询方式。
2、两者使用的组件不同，数据库的读写是通过ADO.NET，而文本文件是通过文件系统读写。使用数据库可不用管磁盘IO这方面的问题，但文本文件的话，就要你自己来处理了，频不频繁就看数据量的大小和你的程序了。
3、你首先应该要解决的是UI更新比较耗时这个问题，如果只是画一条曲线和显示一些文本，应该不会非常耗时的。至于要从哪里读数据，等你的框架先确定下来再说。

Answer 4

1、框架没有固定的形式，要看你的需求来定，要不要数据库取决于你将来是否需要进行历史数据的查询和具体的查询方式。
2、两者使用的组件不同，数据库的读写是通过ADO.NET，而文本文件是通过文件系统读写。使用数据库可不用管磁盘IO这方面的问题，但文本文件的话，就要你自己来处理了，频不频繁就看数据量的大小和你的程序了。
3、你首先应该要解决的是UI更新比较耗时这个问题，如果只是画一条曲线和显示一些文本，应该不会非常耗时的。至于要从哪里读数据，等你的框架先确定下来再说。的确是的，我现在没有查询需求，现在的方案是30s存一次文件，但是ui显示可能要显示多条曲线，ui耗时搞了几天了。所以昨天发帖时其实我有点想换方案，存数据库，然后读取数据库更新ui

Answer 5

采集的同时，需要看到数据的变化趋势，文本我甚至都可以不显示了，但是曲线怎么办呢，发现zedgraph做曲线显示，一旦点数对比较多时，就很卡。

Answer 6

我有时候图省事,会动态画一些label上去显示数据,这样比用datatable效率高很多
当然数据量大的时候,或者比较复杂,或者数据本来就是存放在datatable里了,也会用datagridview来显示

Answer 7

是的，数据的文本显示我现在就是用动态lbl，放弃了之前的dgv显示，只是在数据回放的时候，重新载入所有数据来显示到dgv

Answer 8

1、框架没有固定的形式，要看你的需求来定，要不要数据库取决于你将来是否需要进行历史数据的查询和具体的查询方式。
2、两者使用的组件不同，数据库的读写是通过ADO.NET，而文本文件是通过文件系统读写。使用数据库可不用管磁盘IO这方面的问题，但文本文件的话，就要你自己来处理了，频不频繁就看数据量的大小和你的程序了。
3、你首先应该要解决的是UI更新比较耗时这个问题，如果只是画一条曲线和显示一些文本，应该不会非常耗时的。至于要从哪里读数据，等你的框架先确定下来再说。我是不是可以在数据处理线程吧处理好的数据放入队列，然后再在画曲线的线程取队列数据。这样会不会好一点

Answer 9

楼主可以选择耗资源小的MySQL数据库，或选择不用安装有点像直接操作文件的SQLite来保存数据。计算一下单片机采样给上位机返回数据的频率是多少，如果是频率过高而造成上位机界面刷新较卡的，可不可考虑采集n次之后再刷新界面，n值要自己测试的。如果像51单片机这种，一般都不会卡。再者你的采集器是一个还是多个呢。单片机编写的往往都是裸机程序，考虑到CPU和外围资源的局限性，而电脑的应用程序是运行在操作系统上，操作硬件的细节都是操作系统干的，至少数据库写入是否频繁操作硬盘，由运行着的数据库服务帮你做最优的决定，再者，电脑的硬件资源比单片机丰富很多，不用担忧，你只管优化你的代码，以测试为准即可。

Answer 10

不要在数据处理线程去更新UI啊
线程里面，要做的工作，就是把收集来的数据，放到你的缓冲队列中。
然后在主线程（界面线程），用一个timer（设置的时间以不影响UI操作为基础的最小值），每隔一段时间，就去读取缓冲队列，如果缓冲队列不为空，就把里面的数据取出来做展示（曲线，图表什么的）。。
这样做，即使你数据收集的速度大于UI更新的速度，也是可以接受的，但是如果数据收集速度和UI更新速度相差太大，导致缓冲队列把PC的内存占满而溢出，那你就要想其他办法了

Answer 11

不要在数据处理线程去更新UI啊
线程里面，要做的工作，就是把收集来的数据，放到你的缓冲队列中。
然后在主线程（界面线程），用一个timer（设置的时间以不影响UI操作为基础的最小值），每隔一段时间，就去读取缓冲队列，如果缓冲队列不为空，就把里面的数据取出来做展示（曲线，图表什么的）。。
这样做，即使你数据收集的速度大于UI更新的速度，也是可以接受的，但是如果数据收集速度和UI更新速度相差太大，导致缓冲队列把PC的内存占满而溢出，那你就要想其他办法了现在是在主线程用定时器在更新曲线，但是会阻塞主线程的数据接受，但是我开新线程来更新曲线，看上去貌似可以了，但是偶尔程序会自动退出。还在找原因

Answer 12

不要在数据处理线程去更新UI啊
线程里面，要做的工作，就是把收集来的数据，放到你的缓冲队列中。
然后在主线程（界面线程），用一个timer（设置的时间以不影响UI操作为基础的最小值），每隔一段时间，就去读取缓冲队列，如果缓冲队列不为空，就把里面的数据取出来做展示（曲线，图表什么的）。。
这样做，即使你数据收集的速度大于UI更新的速度，也是可以接受的，但是如果数据收集速度和UI更新速度相差太大，导致缓冲队列把PC的内存占满而溢出，那你就要想其他办法了我下午做了一些测试，数据每2ms上传22字节。在仅接受并存储数据的情况下，我17分钟接受到了1100W字节左右的数据，没有数据丢失。我开一个线程来计算每个字节中的某个特定的值，采取的是队列形式。队列是没有增大，但是貌似阻塞了主线程一样的，14分钟接受了800W字节左右的数据，实际应该接受920W字节的数据。这是怎么回事，难道数据处理线程对主线程有影响。

Answer 13

1、框架没有固定的形式，要看你的需求来定，要不要数据库取决于你将来是否需要进行历史数据的查询和具体的查询方式。
2、两者使用的组件不同，数据库的读写是通过ADO.NET，而文本文件是通过文件系统读写。使用数据库可不用管磁盘IO这方面的问题，但文本文件的话，就要你自己来处理了，频不频繁就看数据量的大小和你的程序了。
3、你首先应该要解决的是UI更新比较耗时这个问题，如果只是画一条曲线和显示一些文本，应该不会非常耗时的。至于要从哪里读数据，等你的框架先确定下来再说。我是不是可以在数据处理线程吧处理好的数据放入队列，然后再在画曲线的线程取队列数据。这样会不会好一点可以的