Comments 30
Интересно. Прочитал на одном дыхании, интересно получить комментарий, где имеет смысл применять данную технику.
Я смог вспомнить один свой проект, в котором была бы уместна данная техника. Я моделировал работу противопожарной службы (многоагентная система), в который агенты обменивались сообщениями. Насколько я помню, я там написал менее эллегантный код, ходя идея динамических событий очень хорошо легла бы на эту задачу. Но мне не кажеться, что это был типичный проект.
Я смог вспомнить один свой проект, в котором была бы уместна данная техника. Я моделировал работу противопожарной службы (многоагентная система), в который агенты обменивались сообщениями. Насколько я помню, я там написал менее эллегантный код, ходя идея динамических событий очень хорошо легла бы на эту задачу. Но мне не кажеться, что это был типичный проект.
да по моему везде имеет смысл использовать если проект достаточно большой, и понадобятся всякие логгинги и аудиты например =)
Недавно курил одну библиотеку для DC-клиентов. Довольно наглядный пример Event Driven'а в рамках чего-то большего, чем реагирование на button_Click: подключение клиента — событие, начало/конец скачки — событие и так далее.
Я посмотрел, выглядит серьезно — с ходу и не понять даже для чего эта библиотека нужна. Расскажите?
Ну как бы это сказать… для создания DC-клиентов :)
Если коротко — везде где нужен loose coupling. Пример — вы хотите чтобы для вашей программы люди могли не напрягаясь писать плагины, события которых могла отлавливать основная программа. Вообще use case'ов очень много.
WPF M-V-VM — оптимальное решение для связи между ViewModel'ами.
Такая техника особенно актуальна для .Net Remoting, т.к. там можно поиметь траблы с получением евентов от удаленного объекта стандартным способом.
Вот статейка www.codeproject.com/KB/IP/remoteevents.aspx
Вот статейка www.codeproject.com/KB/IP/remoteevents.aspx
Замечательная статья, ждем продолжение!1
Еще один потенциальный недостаток такой реализации брокера — утечки памяти. Подписка на событие защищает обьект от GC даже за пределами области видимости. Для обхода этого используются мессенджеры с слабой привязкой.
Еще, можно применить так красиво пропиаренную товарищем mezastel библиотеку PostSharp для AOP программирования… Я думаю, там это можно сделать сверхкрасиво и сверхэффективно.
Ну в плане декларативности тут пойдет либо AOP либо динамические прокси либо, не знаю, использование метапрограммирования в Boo например. Я сейчас уже не сильно использую PostSharp т.к. продукт стал коммерческим. Также, меня начала беспокоить привязка на инфраструктуру PostSharp, которая на самом деле не должна привязываться к скомпилированныи файлам. С другой стороны, с Boo та же самая проблема.
Ну насчет привязки я бы поспорил с Вами в том плане, что используя обычные библиотеки, Вы тоже к ним привязываетесь. Просто PostSharp по сути позволяет делать что-то типа «макросов» или как бы так выразиться, но уже после компиляции. Я не вижу в этом ничего криминального. Это скорее вопрос устоям в голове, идеологии. То что он стал коммерческим, да, грустно, я прочитал Вашу статью уже после этого события. Насчет Boo — не работал с ним. Только косо поглядывал, когда работал в SharpDeveloper :)
Это идеологические вопрос. Делаете постпроцессинг — извольте без привязок. А если есть привязки, то мне легче подвязать Unity.Interceptor и получать то же самое через динамические прокси. Хотя я не спорю, PostSharp мощнее, проблема лишь в том что (я на 99% уверен) он будет нерелевантен с приходом C#5, Boo и Nemerle вообще умрут за ненадобностью, мы обрятем полное разработческое счастье через мета-аттрибуты, мета-методы или как их там назовут.
А еще, некоторая поддержка метапрограммирования есть в F#.
А еще, некоторая поддержка метапрограммирования есть в F#.
По событиям, когда я делал свой проект, поскольку в нем использовалась MEF, то для управления оными, MEF же и использовался. Было очень удобно, но насколько я понимаю, это то же самое что если бы я использовал Ваш подход :)
Есть отличная штука
Есть оличная штука — Reactive Extensions msdn.microsoft.com/en-us/devlabs/ee794896.aspx. По-русски немного вот тут www.gotdotnet.ru/blogs/nesteruk/7388/
Очень удобно.
Очень удобно.
вполне логично, что роутить события между «людьми на поле» должен тот, кто является хозяином этого множества — то есть само поле. человек подходит к полю и начинает «слушать крики», то есть «подписывается на сообщения человеков на поле»…
«Например, реагирование на события в .Net (да и в других языках наверное) сделано на каком-то уж очень несерьезном уровне.»
На нормальном уровне оно сделано. Базовом. Том, который и положен событиям.
А если вы хотите Loose Coupled Events/Event Bus/Service Bus/Message Queue — так возьмите его отдельно и сделайте, ваших требований никто, кроме вас не угадает.
(у нас LCE был написан тупо — события объектов помечались одним атрибутом, методы-подписчики — другим, каждый объект при создании говорил LCE.Register. Просто, быстро, надежно. Сейчас можно было бы то же самое еще и автоматизировать в контейнере)
На нормальном уровне оно сделано. Базовом. Том, который и положен событиям.
А если вы хотите Loose Coupled Events/Event Bus/Service Bus/Message Queue — так возьмите его отдельно и сделайте, ваших требований никто, кроме вас не угадает.
(у нас LCE был написан тупо — события объектов помечались одним атрибутом, методы-подписчики — другим, каждый объект при создании говорил LCE.Register. Просто, быстро, надежно. Сейчас можно было бы то же самое еще и автоматизировать в контейнере)
Ждем следующим статей
А где другие части-то? 4 года уж прошло)
А другие части у меня в блоге :)
Sign up to leave a comment.
Брокеры событий, часть 1