Когда вы говорите «События« Приложения »», вы имеете в виду только те, которые ОПРЕДЕЛЕНЫ на System.Windows.Application?ИЛИ ВЫ ТОЛЬКО имеете в виду любой объявленный event член в ЛЮБОМ классе?
Событие представляет собой набор делегатов метода: когда класс вызывает какое-то событие, он просто начинает вызывать обработчики.Если бы это было асинхронно, то создатель этого события не знал бы, кто мог бы его обработать, и отменяемое событие, такое как Window.Closing, не могло бы быть реализовано - ни один обработчик не гарантированно работал бы синхронно, и производитель всегда мог получитьчерез неотменяемое событие;делая это бесполезным.
Потребители также не знали бы, КОГДА они ПОЛУЧИЛИ событие!Если событие свойства изменено, они могут быть вызваны спустя много времени после того, как это свойство затем изменилось много раз, и кто знает, где приложение будет в это время!
МНОГИЕ СОБЫТИЯ СОЗДАНЫ, ЧТОБЫ БЫТЬ обрабатываться синхронно: приложение только что достигло некоторого состояния, и если вы не можете обработать событие синхронно, то это бесполезно - именно поэтому событие БЫЛО инициировано для начала.
Если события были асинхронными по "по умолчанию «тогда они становятся легко доступной асинхронной« шиной сообщений », и я думаю, что если вы оглянетесь назад, то обнаружите, что это тип« пустой траты времени ».Если все, что вы могли бы сделать в качестве продюсера событий, это запустить какое-то асинхронное неизвестное уведомление, то зачем вам беспокоиться ?!В этот момент производитель может также «скулить», чтобы реализовать какое-то асинхронное сообщение для КАЖДОГО действия - т.е. как бы вы пришли к определению того, что должно вызывать событие?(Где бы вы остановились, не дожидаясь каждого действия; которое вы МОЖЕТЕ реализовать с помощью инструментария.)
Существует множество библиотек с реализациями Application Message Bus.Благодаря уникальной асинхронной шине сообщений, охватывающей все приложения, вы можете иметь представление о службе, которой вы можете «предоставить» уведомление о событии.Если вы более четко определили эту вещь как место, где производители публикуют сообщения, а потребители могут подписаться на них, то у вас есть еще какое-то понятие об услуге, которую вы можете внедрить и использовать.Вы можете создать его для своего приложения, подписаться на существующие события и опубликовать их там, чтобы асинхронные потребители могли обрабатывать их ...
Вместо асинхронного по умолчанию теперь вы МОЖЕТЕ сами выбрать определение асинхронных событий, если выможет спроектировать это конкретное событие, чтобы быть полезным в асинхронной реализации.--- Повторение: вы НЕ будете достоверно знать, по умолчанию, ВОЗ обрабатывает событие, в какое время, если когда-либо.
Вы также можете переопределить любое существующее событие с новой версией Async и добавить синхронный обработчик, которыйповторно публикует каждое событие в асинхронной службе ... Но все сводится к дизайну, который требует некоторого асинхронного события;и асинхронное событие «по умолчанию» стало бы забытым, а кошмар с ошибками - для продюсера, который никогда не узнает, что происходит с событиями, которые он вызывает (и не может отладить их инвариантным способом).
... В библиотеках "Mvvm" есть шины событий;как MVVM Light.