События, колбэки и их альтернативы
Вопрос
Когда вы используете события C#, а когда выбираете другие механизмы (интерфейсы-наблюдатели, IObservable, MediatR, очереди)?
Попробуйте сами
Ответьте вслух за 2 минуты, как на собесе. Потом сверьтесь с тезисами: что прозвучало, а что нет.
Показать ответ и разбор
Коротко
Что должно прозвучать в ответе
События подходят для синхронных уведомлений внутри процесса и UI
Минусы событий: утечки при забытой отписке, синхронность, исключение одного подписчика прерывает остальных
Async-обработчики в событиях плохо работают (async void)
IObservable и Rx для потоков событий с операторами и отпиской через IDisposable
Внутрипроцессный медиатор для доменных событий и слабой связности
Межсервисное взаимодействие через брокер (RabbitMQ, Kafka) с гарантиями доставки
Что могут спросить следом
- Почему async-обработчик события опасен?
- Как избежать утечки при подписке на долгоживущий объект?
Разбор
События C# хороши для простых синхронных уведомлений внутри процесса: UI, INotifyPropertyChanged, хуки в библиотеках. Но у них есть известные минусы. Подписчика держит источник, и забытая отписка даёт утечку. Подписчики вызываются по очереди в том же потоке, и исключение одного прерывает остальных. Асинхронный обработчик вынужденно становится async void: источник не ждёт его завершения, а исключение может уронить процесс.
Если событий много и нужны операторы (фильтрация, буферизация, debounce), беру IObservable и Rx: отписка там через IDisposable, что удобно с using. Для доменных событий в бэкенде использую медиатор или свой диспетчер, где обработчики асинхронные и получаются из DI.
Если событие должно пережить падение процесса или дойти до другого сервиса, это уже задача брокера сообщений: outbox, RabbitMQ или Kafka с гарантией доставки хотя бы один раз и идемпотентными обработчиками.
Ответьте сами, а не прочитайте
В тренажёре вопрос попадёт в повторения и вернётся, когда начнёт забываться. Плюс билеты с зачётом: 20 вопросов, не больше 2 ошибок.