问WinForms多线程绑定场景，最佳实践？

EN

这是一个棘手的问题，因为大多数“解决方案”都会导致大量定制代码和对BeginInvoke()或System.ComponentModel.BackgroundWorker (这本身只是BeginInvoke的瘦包装)的调用。

在过去，我还发现您希望尽快延迟发送INotifyPropertyChanged事件，直到数据稳定为止。处理一个适当更改事件的代码通常需要阅读其他礼仪。您还经常有一个控件，每当许多属性的状态发生变化时，都需要重新绘制自己，而且您不会太频繁地使用该控件来重绘自己。

首先，每个自定义WinForms控件都应该读取它需要在PropertyChanged事件处理程序中自己绘制的所有数据，因此当它是WM_PAINT (OnPaint)消息时，它不需要锁定任何数据对象。控件在获得新数据时不应该立即重新绘制自己；相反，它应该调用Control.Invalidate()。Windows将将WM_PAINT消息合并到尽可能少的请求中，并且只在UI线程没有其他任务时才发送它们。这将使重绘的次数和数据对象被锁定的时间最小化。(标准控件通常使用数据绑定来实现这一点)

数据对象需要记录更改时更改的内容，然后，一旦完成了一组更改，“踢”UI线程到调用SendChangeEvents方法，然后调用PropertyChanged事件处理程序(在UI线程上)对所有已更改的属性进行调用。在运行SendChangeEvents()方法时，必须锁定数据对象，以阻止后台线程更新它们。

每当一组更新从数据库读取bean时，UI线程都可以通过调用BeginInvoke来“踢”。通常情况下，最好使用计时器进行UI线程轮询，因为只有当UI消息队列为空时才发送WM_TIMER消息，从而使UI感觉更响应。

还可以考虑完全不使用数据绑定，每次计时器触发时，让UI询问每个数据对象“更改了什么”。Databinding看起来总是不错的，但很快就会成为问题的一部分，而不是解决方案的一部分。

由于数据对象的锁定/解锁是痛苦的，并且可能不允许从数据库中读取更新，因此您可能希望传递数据对象的UI线程a(虚拟)副本。使数据对象是持久的/不可变的，这样对数据对象的任何更改都会返回一个新的数据对象，而不是更改当前的数据对象。

持久性对象听起来非常慢，但不必是，有关一些指针，请参阅这和那。还可以查看堆栈溢出上的这和那。

还请看一下雷朗-。它的消息批处理可能是有用的。

(对于WPF，我将有一个View-Model，它设置在UI线程中，然后通过后台线程从多线程模型中以“批”的形式更新。但是，与WinForms相比，WPF在组合数据绑定事件方面要好得多。

在这个主题上有一个特定的MSDN文章。但要做好准备，看看VB.NET。

此外，也许您可以使用System.ComponentModel.BackgroundWorker，而不是一般的第二个线程，因为它很好地形式化了与您所描述的生成的后台线程之间的交互。MSDN库中给出的示例相当不错，因此请查看它，以获得如何使用它的提示。

编辑:请注意:如果使用ProgressChanged事件与UI线程通信，则不需要编组。只要需要与UI通信，后台线程就会调用ReportProgress。由于可以将任何对象附加到该事件，因此没有理由进行手动编组。进度是通过另一个异步操作来传递的，因此不需要担心UI处理进度事件的速度，也不需要担心后台线程通过等待事件完成而相互交织。

如果您证明后台线程正在以太快的速度提高进度更改事件，那么您可能想看看UI更新的拉和推模型，这是一篇由Ayende撰写的优秀文章。

是的，所有的书都显示线程结构和调用等。这是完全正确的等等，但是它可能是一个痛苦的代码，而且通常很难组织，这样你就可以为它做适当的测试。

用户界面只需要每秒刷新这么多次，因此性能永远不是问题，轮询也会正常工作。

我喜欢使用由后台线程池不断更新的对象图。他们检查数据值的实际变化，当他们注意到实际的更改时，他们会更新对象图根目录上的版本计数器(或者每个主项上更有意义的内容)，并更新这些值。

然后，您的前台进程可以有一个计时器(默认情况下与UI线程相同)来触发一次左右，并检查版本计数器，如果它更改，则锁定它(以停止部分更新)，然后刷新显示。

这个简单的技术将UI线程与后台线程完全隔离开来。