События предназначены для отделения одной области от другой .
Иногда это включает в себя некоторое асинхронное поведение , которое может быть дополнительной функцией, но не является обязательным. Например, если вы хотите обеспечить быструю обратную связь с пользователем в графическом интерфейсе, а часть вашего кода выполняется слишком медленно (если только его не нужно завершить до предоставления обратной связи), тогда обычный вызов может выполнить быстрые коды и создать событие для остальных, затем предоставьте обратную связь GUI, не дожидаясь фактической обработки события. Это событие сохраняется в очереди, и один или несколько потоков обрабатывают эту очередь в своем собственном темпе.
Для синхронных событий это действительно полезно для межмодульной связи, где два модуля не имеют зависимостей времени компиляции друг от друга . Оба могут знать о классе событий и «маршрутизаторе событий»:
- один модуль создает событие и вызывает маршрутизатор,
- маршрутизатор знает (из предыдущей конфигурации), какой другой модуль должен его получить, и отправляет его принимающему модулю.
Ни один из модулей не знает о другом, таким образом, концепция развязки. Очень хорошо, если оба должны поддерживаться отдельно: -)
Существует множество вариаций для некоторых тем, таких как:
- вещание на многие приемники
- переключение при сбое (если приемник временно не работает, он запускается снова; событие будет доставлено, когда приемник включится и снова будет зарегистрирован)
- аудит : технический модуль может получать события, нацеленные на другие модули, и регистрировать их
- ...
Изменение объектов Домена с помощью событий кажется немного странным . Является ли упомянутое выше разделение действительно оправданным?
Однако я бы не дал определенного мнения, прежде чем понять, что вы имеете в виду.