никто не должен. у тебя есть ивент "что-то произошло" - тот кто ивент слушает решает что с ним надо делать
давай по правильному — какую задачу решаешь?
Тогда в горизонтальном модуле будет для сотни эвентов написано что с ними делать
да, для сотни ивентов будет написано что с ними делать. и это нормально. ну или у тебя "для сотни ивентов одинаково в лог вывести"? это декоратор над диспатчером может делать - ему не надо знать ничего про конкретные ивенты, будет выводить какие-то стандартные вещи вроде имени
одинаково вывести кастомное сообщение для каждого типа, но это не просто "лог"
Для просто лога и так есть декоратор
ну вот ты уточняй что такого непростого в этом "логе"
скажи что делаешь? какая задача? что такое горизонатльный модуль?
Не претендую на корректность наименований, не могу более подходяшего слова вспомнить. Типо модуль не имеющий прямых зависимостей, но прогоняющий множество других через себя посредством интерфейсов, типо в который можно плагиниться через реализацию его интерфейсов. Кроме эвентов там и другие есть, типо опрос для снмп - каждый модуль для него реализует у себя адаптер если есть что опубликовать.
ну и обогащай этим модулем свои события в своих модулях... зависимость стабильная, судя по всему это нормально и хоорошо по дизайну
так и делает))00
Я не уверен что правильно понимаю. Например ты предлагаешь для аудитов заинжектить логгер в каждый модуль где это нужно?
А понял кажется, ты хочешь события свои закрыть интерфейсом И чтобы все события этого интерфейса модуль переваривал ? Я бы сделал так, чтобы в событие была мета, что событие «logged” или интерфейс повесил И на уровне приложения сделал бы обогатитель, который бы превращал события в новые для твоего лагер-модуля
Нюанс в том что для многих таких концернов обогатитель фактически не нужен т.к. все уже есть в евенте
Ну сделай мету настраиваемой #[Logged(needRich: true)] Или #[Logged(needRich: false)] сквозная логика она такая
Ну грубо говоря тоже самое только без интерфейсов а на атрибутах
Обсуждают сегодня