是否可以在事件处理程序中执行复杂的计算？

Question

当有人在事件处理程序中执行复杂的计算时，它被认为是一种不好的做法吗？

计算混乱的.OnResize事件处理程序是否会产生性能损失？

如果是这样，如何绕过他们？ （特别是.Print事件，因为这是e.Graphics的用途）

Answer 1

这不算坏，不是这样。

如果您的代码感觉混乱，请将其清理干净 - 重构它。

除非事件处理程序应该快（比如一个Paint事件处理程序），否则让它做很多工作都没有问题。

如果您要进行非常密集的计算并且仍需要具有响应式UI，则需要在单独的线程上运行计算。

Answer 2

我认为你的意思是Paint事件，而不是Print。当您需要流畅的GUI用户交互时，不建议使用：风险是您可以从GUI线程中窃取CPU时间，并且应用程序将显得缓慢且无响应。如果这些计算确实是用户交互的问题，那么出路就是在单独的线程上进行计算，提前计算结果并将它们存储在单独的缓冲区中。

Answer 3

通常，不要在事件处理程序中保留大量计算。在事件处理程序调用中，逐个调用回调，如果其中一个回调引发异常，则其他回调不会收到该事件。将计算结果发布到一个线程，以便其他回调不受影响。

Answer 4

事件通常用于事件驱动的系统，通常由用户驱动或用户参与。因此，保持处理简短和甜蜜是一个好主意。

有时会调用事件以进行一些处理 - 应用格式化，提示用户，为调用代码提供“自定义”正在进行的操作的机会。这类似于策略模式（http://en.wikipedia.org/wiki/Strategy_pattern）。

为了更进一步，策略模式是与用户签订合同的好方法，关于他们如何对流程应该如何发生发表意见。例如：

假设您正在编写一个网格控件，用户可以在其中指定每个单元格的格式。有事件：

• 用户必须订阅FormatCell事件

更接近战略模式：

• 用户必须使用FormatCell方法创建一个实现ICellFormatter的类，并通过属性，构造函数参数等将其传递给网格控件。

您可以看到事件路线对用户来说“更容易”。但我个人更喜欢第二种方法 - 你正在创建一个明确的类，它的工作是处理单元格格式。在这种情况下，对我来说似乎更明显的是，FormatCell方法可以执行某种程度的处理;而不是使用事件来执行某些任务，这似乎有点懒惰的设计。 （Paint是一个“事件”？不是真的，这是你的代码所要求的东西）