Желательно ли выполнять сложные вычисления в обработчике событий?

Question

Считается ли это плохой практикой, когда кто-то выполняет сложные вычисления в обработчике событий?

Имеет ли обработчик событий .OnResize помехи в производительности?

Если так, как обойти их? (особенно событие .Print, так как именно это привлекает e.Graphics)

Answer 1

Он не считается плохим, как таковой.

Если ваш код кажется беспорядочным, очистите его - выполните рефакторинг.

Если обработчик событий не будет быстрым (скажем, обработчик событий Paint), нет проблем с тем, чтобы он выполнял много работы.

Если у вас есть очень интенсивные вычисления, и вам все еще нужен отзывчивый пользовательский интерфейс, вам нужно запуститьрасчеты в отдельном потоке.

Answer 2

Я думаю, вы имеете в виду событие Paint, а не Print. Это не рекомендуется, когда вам нужно плавное взаимодействие с пользователем графического интерфейса: есть риск, что вы можете украсть процессорное время из потока графического интерфейса, и приложение будет выглядеть вялым и не отвечающим. Если эти вычисления действительно являются проблемой для взаимодействия с пользователем, выходом является выполнение расчетов в отдельном потоке, предварительное вычисление результатов и их сохранение в отдельном буфере.

Answer 3

События обычно используются в управляемой событиями системе, обычно той, которая управляется пользователем или в которой участвует пользователь. Таким образом, это хорошая идея, чтобы продолжать обработку короткой и сладкой.

Иногда события вызываются для того, чтобы выполнить некоторую обработку - применить форматирование, предложить пользователю, дать возможность вызывающему коду «настроить» происходящее. Это похоже на шаблон стратегии (http://en.wikipedia.org/wiki/Strategy_pattern).

Чтобы продвинуться дальше, шаблон стратегии - это хороший способ заключить с пользователем договор о том, как они могут высказать свое мнение о том, как должен происходить процесс. Например:

Допустим, вы пишете элемент управления сеткой, где пользователь может диктовать форматирование для каждой ячейки. С событиями:

• Пользователь должен подписаться на событие FormatCell

Что-то ближе к шаблону стратегии:

• Пользователь должен создать класс, реализующий ICellFormatter, с методом FormatCell и передать его в элемент управления grid - через свойство, параметр конструктора и т. Д.

Вы видите, что маршрут события «проще» для пользователя. Но лично я каждый раз предпочитаю второй метод - вы создаете четкий класс, задачей которого является работа с форматированием ячеек. В этом случае мне также кажется более очевидным, что метод FormatCell может выполнять некоторую степень обработки; вместо того, чтобы использовать Событие для выполнения какой-то задачи, которая кажется немного ленивой. (Paint - это «событие»? .. не совсем, это что-то запрошенное вашим кодом)

Answer 4

Как правило, не храните много вычислений внутри обработчика событий. В вызове обработчика события обратные вызовы вызываются один за другим, и если один из обратных вызовов выдает исключение, то другие обратные вызовы не получают событие. Опубликуйте вычисление в потоке, чтобы не затронуть другие обратные вызовы.