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

Question

Что касается пользовательских событий в .NET, какой шаблон проектирования предпочтителен для передачи аргументов событий? Должен ли у вас быть отдельный производный класс EventArgs для каждого события, которое может быть вызвано, или допустимо иметь один класс для событий, если они все вызваны событиями из одного класса?

Answer 1

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

Это могут быть существующие классы фреймворка (например, System.Component.CancelEventArgs, если все, что вы хотите сделать, это дать обработчику событий возможность отменить действие.

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

Answer 2

Я обычно создаю базовый класс EventArgs, который имеет общие данные для каждого события. Если с конкретным событием связано больше данных, я создаю подкласс для этого события; в противном случае я просто использую базовый класс.

Answer 3

Я, как и OAB, создал бы собственный «базовый» класс args, который расширяет EventArgs, добавляя данные, специфичные для компонента или приложения, в котором я его использую. Например. в приложении экспорта бухгалтерского учета моя базовая ExportEventArgs добавит свойство AccountNo.

Answer 4

Это зависит от того, что это за события, но по большей части ради того, кто бы ни собирался использовать ваши события, создайте один собственный класс, производный от EventArgs.