是否建议在事件处理程序中执行复杂的计算？
当有人在事件处理程序中执行复杂的计算时，这是否被认为是一种不好的做法？
计算混乱的 .OnResize 事件处理程序是否会造成性能损失？
如果是这样，如何绕过它们？ （尤其是 .Print 事件，因为这就是 e.Graphics 上的内容）
Is it considered a bad practice when someone performs complicated calculations in an event handler?
Does a calculation-cluttered .OnResize event handler has performance penalties?
If so how to make your way around them? (especially the .Print event, since thats what draws on e.Graphics)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
它不被认为是坏事，并非如此。
如果您的代码感觉混乱，请清理它 - 重构它。
除非事件处理程序应该快速（例如
Paint事件处理程序），否则让它执行大量工作是没有问题的。如果您需要进行非常密集的计算并且仍然需要具有响应式 UI，则需要在单独的线程上运行计算。
It is not considered bad, not as such.
If your code feels cluttered, clean it up - refactor it.
Unless the event handler should be fast (say a
Paintevent handler), there is no problem in having it do lots of work.If you have very intensive calculations to do and still need to have a responsive UI, you need to run the calculations on a separate thread.
我认为你的意思是绘制事件，而不是打印事件。当您需要流畅的 GUI 用户交互时，不建议这样做：风险是您可能会从 GUI 线程中窃取 CPU 时间，并且应用程序将显得缓慢且无响应。如果这些计算确实对用户交互造成问题，那么解决办法就是在单独的线程上进行计算，提前计算结果并将其存储在单独的缓冲区中。
I think you mean Paint event, not Print. It's not recommended when you need smooth GUI user interaction: the risk is you can steal CPU time from GUI thread and the app will appear sluggish and unresponsive. If these calculations are really a problem for user interaction, the way out is doing calculations on a separate thread, calculating results in advance and storing them in a separate buffer.
通常，不要在事件处理程序中保留大量计算。在事件处理程序调用中，回调被一一调用，如果其中一个回调抛出异常，则其他回调不会接收到该事件。将计算发布到线程，以便其他回调不受影响。
Generally, do not keep a lot of calculations inside an event handler. In event handler call, callbacks are called one by one and if one of the callbacks throws an exception then other callbacks do not receive the event. Post the calculation to a thread so that other callbacks are not affected.
事件通常用在事件驱动系统中，通常由用户驱动或用户参与的系统。因此，保持处理过程简短而甜蜜是个好主意。
有时，调用事件是为了进行一些处理 - 应用格式、提示用户、为调用代码提供“自定义”正在发生的事情的机会。这类似于策略模式（http://en.wikipedia.org/wiki/Strategy_pattern）。
更进一步来说，策略模式是与用户签订合同的好方法，让用户了解如何对流程应该如何发生发表意见。例如：
假设您正在编写一个网格控件，用户可以在其中指定每个单元格的格式。使用事件：
使用更接近策略模式的东西：
您可以看到事件路线对于用户来说“更容易”。但我个人每次都更喜欢第二种方法 - 您正在创建一个明确的类，其工作是处理单元格格式。在这种情况下，FormatCell 方法可以执行某种程度的处理，这对我来说似乎更为明显；而不是使用事件来执行某些任务，这看起来有点懒惰的设计。 （绘画是一个“事件”？..不是真的，这是您的代码所要求的）
Events are usually used in an event-driven system, usually one driven by the user or where a user is involved. As such, it's a good idea to keep processing short and sweet.
Sometimes, events are called in order to do some processing - apply formatting, prompt the user, provide a chance for the calling code to 'customise' what's going on. This is similar to the strategy pattern (http://en.wikipedia.org/wiki/Strategy_pattern).
To take it a step further, the strategy pattern is a good way of having a contract with the user about how they can have their say about how a process is supposed to happen. For example:
Let's say you're writing a grid control, where the user can dictate formatting for each cell. With events:
With something closer to a strategy pattern:
You can see that the event route is 'easier' for the user. But personally I prefer the second method every time - you're creating a clear-cut class whose job it is to deal with cell formatting. It also seems more obvious to me in that case that the FormatCell method could perform some degree of processing; rather than using an Event to perform some task, which seems a bit of lazy design. (Paint is an "event"?.. not really, it's something requested of your code)