События должны определяться задачей. Почему они у вас разрастаются?
Как и всегда добавляются новые требования. Самое простое решение которое предлагает аггрегатор — добавить новое событие и подписаться везде где это нужно. Вот только не всегда это адекватное решение.
Это проблема тех, кто его неправильно использует.
не используя нет таких проблем. Всегда конечно есть другие.
Это называется «инкапсуляция». Что в этом плохого?
При такой «Инкапсуляции» маршрут данных в приложении тяжело менять.
Потому что у вас единственное, что определяет событие — это его тип?
В системе уже используется событие с определенным типом, теперь я хочу пере использовать тип события, но не могу. Уже есть источники и подписчики, а мне нужно что бы источники и подписчики нового события ни как не были связаны с источниками и подписчиками уже используемого. Это тяжко сделать с EventAggregator который предоставляет Prism, Catel и тд.
У вас есть претензии к событийной модели? Понимаю, окей. Откажитесь от событийной модели вовсе.blockquote>
Уже.
О каком интерфейсе речь? Что хочу публикую, что хочу слушаю?
Вот у вас есть интерфейс сервиса. Если конкретная реализация этого сервмса внутри себя подписывается или публикует что либо, через аггрегатор. Что нужно сделать для замены реализации?
Не является. Но часто, в том же Prism, EventAggregator резолвится через IoC в конструктор.
Хуже всего что все примеры и документация на это заточены. Да это очень просто сделать, а вот сопровождать тяжело.
Не надо подписываться на ненужные события. А то и не не надо их генерировать :)
С этим спорить сложно.
Агрегатор собирает однотипные события в единый поток, позволяя реакторам подписываться на этот тип событий только в одном месте, а не переписывать код каждого наблюдателя при добавлении нового эмиттера.
При добавлении нового эмитера нужно дорабатывать все реакторы которые ожидают новое событие.
кто его ограничивает? Как скрыть не нужные события? В наблюдателе все это ограничивается интерфейсом, если у интерфейса десятки методов для подписки, то чем это отличается от аггрегатора?
Чем она отличная? Тем, что количество связей растет с неимоверной скоростью?
именно об этом я и пишу, количество событий начинает разрастаться.
...EA — это всего лишь промежуточный обсервер. Вам никто не мешает сделать так же.
не мешает, но как обычно используют EventAggregator — проброс в конструктор и подписка на любые доступные события.
А что мешает EA взаимодействовать с реализацией интерфейса?
Практика использования — Подписывайся когда хочешь и на что хочешь.
Добавили новые события — поправили тех, кто от этих событий зависит. Все как с обсервером.
нет. Если объект сам решает на что ему подписываться.
Да, просто не в описанной вами реализации.
все персонажи вымышленные совпадения случайны.
А может это проблема того, что у вас в системе зачем-то должны быть уникальные типы событий?
Уникальные типы появляются, когда одни и те же данные имеют разное предназночение. Например строка может быть сообщением об ошибке, заголовком окна или еще чем то.
Пока что запутыванию кода способствует событийная модель (что логично, потому что это дополнительный уровень косвенного взаимодействия) и лишние единые точки входа.
А разве EventAggregator не основан на событийной модели? Название даже содержит Event…
А чья? В событийной модели кто-то должен отвечать за подписку/отписку. И этот кто-то, что характерно, не зависит от того, аггрегатор у вас, или просто обсервер. Так что пункт не засчитан.
Отличная система где все на все подписываются. В отличии от EventAggregator с его конкретным типом события, Observer взаимодействует с реализацией интерфейса. Реализация приходит в конструкторе или методе — наблюдатель не выбирает за чем наблюдать.
Во-первых, нет. Подписка/отписка осталась той же самой — аггрегатор на все источники, все потребители на аггрегатор.
Речь про добавление новых событий в системе. Вы использовали EventAggregator в своих проектах?
Иии что? До тех пор, пока компонент зависит от абстракции агрегатора, а не от конкретной реализации, DIP не нарушен.
))) Зависимость не от аггрегатора, а от конкретных событий.
lair мне кажется вы просто не сталкивались с EventAggregator. Это очень круто когда в системе 300 событий половина из которых дубляж, просто потому что событие с таким типом уже где то там используется и что бы ничего не сломать нужно создать то же самое событие но по другому назвать. А еще в системе присутствует не явная зависимость от последовательности подписки, и если ее нарушить все рухнет. Зафига там что то проектировать улучшать? Сделал новое событие, а потом еще и еще… EventAggregator способствует запутыванию кода.
Схемы выбраны как абстракция. В схему можно заменить на систему фильтров — где Power и switch — критерии поиска, а Led'ы — результат фильтрации. Фантазировать можно как угодно.
Как и всегда добавляются новые требования. Самое простое решение которое предлагает аггрегатор — добавить новое событие и подписаться везде где это нужно. Вот только не всегда это адекватное решение.
не используя нет таких проблем. Всегда конечно есть другие.
При такой «Инкапсуляции» маршрут данных в приложении тяжело менять.
В системе уже используется событие с определенным типом, теперь я хочу пере использовать тип события, но не могу. Уже есть источники и подписчики, а мне нужно что бы источники и подписчики нового события ни как не были связаны с источниками и подписчиками уже используемого. Это тяжко сделать с EventAggregator который предоставляет Prism, Catel и тд.
Вот у вас есть интерфейс сервиса. Если конкретная реализация этого сервмса внутри себя подписывается или публикует что либо, через аггрегатор. Что нужно сделать для замены реализации?
Хуже всего что все примеры и документация на это заточены. Да это очень просто сделать, а вот сопровождать тяжело.
да. Вот только EventAggregator так просто применить не по месту.
С этим спорить сложно.
При добавлении нового эмитера нужно дорабатывать все реакторы которые ожидают новое событие.
При добавлении нового события нужно не забыть подписать лог? А что это даст кроме информации что событие произошло?
Если подписка будет происходить вне эмиттера и реактора то да, иначе с заменой одной реализации конкретного эмиттера или реактора возникнут проблемы.
И как он ее упростит?
В случае наблюдателя имеется ограниченный набор на что можно подписаться, с агрегацией событий это не так.
Проходят через одну точку? Регистрируются да, но уж точно не проходят.
Система спама, контролировать очень сложно.
именно об этом я и пишу, количество событий начинает разрастаться.
не мешает, но как обычно используют EventAggregator — проброс в конструктор и подписка на любые доступные события.
Практика использования — Подписывайся когда хочешь и на что хочешь.
нет. Если объект сам решает на что ему подписываться.
все персонажи вымышленные совпадения случайны.
Уникальные типы появляются, когда одни и те же данные имеют разное предназночение. Например строка может быть сообщением об ошибке, заголовком окна или еще чем то.
Даже у совершенного оружия есть недостаток — его владелец ©. Многие считают, что при использование EventAggregator не будет проблем, они ошибаются. Очень тяжело отслеживать события.
А разве EventAggregator не основан на событийной модели? Название даже содержит Event…
Отличная система где все на все подписываются. В отличии от EventAggregator с его конкретным типом события, Observer взаимодействует с реализацией интерфейса. Реализация приходит в конструкторе или методе — наблюдатель не выбирает за чем наблюдать.
Речь про добавление новых событий в системе. Вы использовали EventAggregator в своих проектах?
))) Зависимость не от аггрегатора, а от конкретных событий.
lair мне кажется вы просто не сталкивались с EventAggregator. Это очень круто когда в системе 300 событий половина из которых дубляж, просто потому что событие с таким типом уже где то там используется и что бы ничего не сломать нужно создать то же самое событие но по другому назвать. А еще в системе присутствует не явная зависимость от последовательности подписки, и если ее нарушить все рухнет. Зафига там что то проектировать улучшать? Сделал новое событие, а потом еще и еще… EventAggregator способствует запутыванию кода.