Как стать автором
Обновить
9
Карма
0
Рейтинг

Пользователь

  • Подписчики 2
  • Подписки

EventAggregator — антипаттерн

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

EventAggregator — антипаттерн

События должны определяться задачей. Почему они у вас разрастаются?

Как и всегда добавляются новые требования. Самое простое решение которое предлагает аггрегатор — добавить новое событие и подписаться везде где это нужно. Вот только не всегда это адекватное решение.

Это проблема тех, кто его неправильно использует.

не используя нет таких проблем. Всегда конечно есть другие.

Это называется «инкапсуляция». Что в этом плохого?

При такой «Инкапсуляции» маршрут данных в приложении тяжело менять.

Потому что у вас единственное, что определяет событие — это его тип?

В системе уже используется событие с определенным типом, теперь я хочу пере использовать тип события, но не могу. Уже есть источники и подписчики, а мне нужно что бы источники и подписчики нового события ни как не были связаны с источниками и подписчиками уже используемого. Это тяжко сделать с EventAggregator который предоставляет Prism, Catel и тд.

У вас есть претензии к событийной модели? Понимаю, окей. Откажитесь от событийной модели вовсе.blockquote>
Уже.

EventAggregator — антипаттерн

Сегодня паттерн применяешь по месту, а завтра его превращают в анти. Вот чья это проблема?

EventAggregator — антипаттерн

а какая польза будет от такого логирования?

EventAggregator — антипаттерн

агрегация ни как не поддается контролю.

EventAggregator — антипаттерн

О каком интерфейсе речь? Что хочу публикую, что хочу слушаю?

Вот у вас есть интерфейс сервиса. Если конкретная реализация этого сервмса внутри себя подписывается или публикует что либо, через аггрегатор. Что нужно сделать для замены реализации?

EventAggregator — антипаттерн

Не является. Но часто, в том же Prism, EventAggregator резолвится через IoC в конструктор.
Хуже всего что все примеры и документация на это заточены. Да это очень просто сделать, а вот сопровождать тяжело.

EventAggregator — антипаттерн

ну и вообще, любой паттерн хорош тогда, когда он применен по месту

да. Вот только EventAggregator так просто применить не по месту.

EventAggregator — антипаттерн

Не надо подписываться на ненужные события. А то и не не надо их генерировать :)

С этим спорить сложно.

Агрегатор собирает однотипные события в единый поток, позволяя реакторам подписываться на этот тип событий только в одном месте, а не переписывать код каждого наблюдателя при добавлении нового эмиттера.

При добавлении нового эмитера нужно дорабатывать все реакторы которые ожидают новое событие.

EventAggregator — антипаттерн

Подпишусь логгером на все события агрегатора

При добавлении нового события нужно не забыть подписать лог? А что это даст кроме информации что событие произошло?

EventAggregator — антипаттерн

У каждого эмиттера событий в идеале только один подписчик — агрегатор, а каждый реактор на события подписывается только на один эмиттер — агрегатор.

Если подписка будет происходить вне эмиттера и реактора то да, иначе с заменой одной реализации конкретного эмиттера или реактора возникнут проблемы.

EventAggregator — антипаттерн

Дело не в реализации. И как вы их будете отслеживать?

EventAggregator — антипаттерн

кто его ограничивает? Как скрыть не нужные события? В наблюдателе все это ограничивается интерфейсом, если у интерфейса десятки методов для подписки, то чем это отличается от аггрегатора?

EventAggregator — антипаттерн

Сначала принимается решение использовать событийную модель, а потом для её упрощения вводится EventAggregator.

И как он ее упростит?

EventAggregator — антипаттерн

Так решает и обсервер.

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

EventAggregator — антипаттерн

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

Проходят через одну точку? Регистрируются да, но уж точно не проходят.

EventAggregator — антипаттерн

Да. Обратная сторона одного события. Всю информацию засунуть в одно событие, пусть подписчик разбирается сам.

Система спама, контролировать очень сложно.

EventAggregator — антипаттерн

Чем она отличная? Тем, что количество связей растет с неимоверной скоростью?

именно об этом я и пишу, количество событий начинает разрастаться.

...EA — это всего лишь промежуточный обсервер. Вам никто не мешает сделать так же.

не мешает, но как обычно используют EventAggregator — проброс в конструктор и подписка на любые доступные события.

А что мешает EA взаимодействовать с реализацией интерфейса?

Практика использования — Подписывайся когда хочешь и на что хочешь.

Добавили новые события — поправили тех, кто от этих событий зависит. Все как с обсервером.

нет. Если объект сам решает на что ему подписываться.

Да, просто не в описанной вами реализации.

все персонажи вымышленные совпадения случайны.

А может это проблема того, что у вас в системе зачем-то должны быть уникальные типы событий?

Уникальные типы появляются, когда одни и те же данные имеют разное предназночение. Например строка может быть сообщением об ошибке, заголовком окна или еще чем то.

Это уж точно не проблема EA.

Даже у совершенного оружия есть недостаток — его владелец ©. Многие считают, что при использование EventAggregator не будет проблем, они ошибаются. Очень тяжело отслеживать события.

Пока что запутыванию кода способствует событийная модель (что логично, потому что это дополнительный уровень косвенного взаимодействия) и лишние единые точки входа.

А разве EventAggregator не основан на событийной модели? Название даже содержит Event…

EventAggregator — антипаттерн

А чья? В событийной модели кто-то должен отвечать за подписку/отписку. И этот кто-то, что характерно, не зависит от того, аггрегатор у вас, или просто обсервер. Так что пункт не засчитан.

Отличная система где все на все подписываются. В отличии от EventAggregator с его конкретным типом события, Observer взаимодействует с реализацией интерфейса. Реализация приходит в конструкторе или методе — наблюдатель не выбирает за чем наблюдать.
Во-первых, нет. Подписка/отписка осталась той же самой — аггрегатор на все источники, все потребители на аггрегатор.
Речь про добавление новых событий в системе. Вы использовали EventAggregator в своих проектах?

Иии что? До тех пор, пока компонент зависит от абстракции агрегатора, а не от конкретной реализации, DIP не нарушен.
))) Зависимость не от аггрегатора, а от конкретных событий.

lair мне кажется вы просто не сталкивались с EventAggregator. Это очень круто когда в системе 300 событий половина из которых дубляж, просто потому что событие с таким типом уже где то там используется и что бы ничего не сломать нужно создать то же самое событие но по другому назвать. А еще в системе присутствует не явная зависимость от последовательности подписки, и если ее нарушить все рухнет. Зафига там что то проектировать улучшать? Сделал новое событие, а потом еще и еще… EventAggregator способствует запутыванию кода.

EventAggregator — антипаттерн

Схемы выбраны как абстракция. В схему можно заменить на систему фильтров — где Power и switch — критерии поиска, а Led'ы — результат фильтрации. Фантазировать можно как угодно.

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность