mezastel Jun 24 2010 at 01:43

Брокеры событий, часть 1

7 min

Вообще в сложных, динамических системах очень сложно угнаться за меняющейся организацией компонентов, и если мы еще кое-как (это в 21-м то веке!) разурлили проблему создания компонентов с помощью специализированных контейнеров, то взаимодействие из между собой нам все еще полностью не подвластно. Например, реагирование на события в .Net (да и в других языках наверное) сделано на каком-то уж очень несерьезном уровне. И естественным образом в этой задаче появляются всякие инфраструктурные решения, о которых мы и поговорим.

Задача

Для большинства разработчиков, особенно разработчиков которые в аутсорсах посиживают, реагирование на события (я имею ввиду в основном event-ы) либо не существует совсем, либо существует со страшной силой, но в очень предсказуемом ключе. Наприемер, когда кто-то нажимает на кнопочку и отрабатывается событие button_Click.

Как только с событиями нужно работать вплотную, игра тут же останавливается. Вот вам пример – берем футболиста и тренера:

public class FootballPlayer { public string Name { get;set; } public void Score() { var e = Scored; if (e != null) e(this, new EventArgs()); } public event EventHandler Scored; } public class FootballCoach { public void Watch(FootballPlayer p) { p.Scored += (_, __) => { Console.WriteLine("I'm happy that {0} scored", p.Name); }; } }

В этом случае подписка и уведомление работают хорошо:

var p = new FootballPlayer { Name = "Arshavin" }; var c = new FootballCoach(); c.Watch(p); p.Score(); // coach saw it!

Весь прикол тут в том, что когда вы скопируете объект (будь то через MemberwiseClone() или deep copy с помощью BinaryFormatter), все подписки этого объекта будут потеряны.

var p2 = c.Clone(); // deep copy :) p.Score(); 

Подписки можно, конечно, востановить руками или начать использовать вместо событий просто наборы делегатов или…. там, Expression<T>, что-то в этом роде. Но это только часть проблемы.

Следующая часть проблемы состоит в том, что в один прекрасный момент вы захотите чтобы ваши объекты подписывались на события автоматически. Например, вышел игрок на поле – тренер начинает за ним следить. С “отписками”, кстати, то же самое. Если все утрировать, получится примерно следующее:

class FootballCoach { public FootballCoach(FootballPlayer[] players) { foreach (var p in players) { p.EntersField += new EventHandler(StartWatchingPlayer); p.LeavesField += new EventHandler(StopWatchingPlayer); } } } 

И так далее до посинения – в каждом StartXxx вы будете подписываться, в каждом EndXxx отписываться. Но и это еще не все.

Представьте теперь, что в системе таких объектов много. Все они посылают всем другим сообщения. Если делать пописки через +=, мы получим зверскую связанность и полную нетестируемость (а тестировать сообщения вообще сложно) нашего кода.

Ну и наконец надо и “о бедной конфигурации замолвить слово”. Ведь иногда хочется получать уведомления определенного типа вне зависимости от того, кто их послал. Например, судье толком все равно, кто на него матерится – игрок или тренер. (Это я так, символично.) А еще, не поверите, иногда хочется делать всякие хитрые преобразования вроде реагирования на события пакетами по 100 штук, раз в час, только в пятницу 13го в полнолуние, и т.п. К чему нынешнее положение дел не очень-то предрасположено.

Pub-sub

У среднестатистичного разработчика сразу появляется желание написать свой event broker. А что, почему бы и нет. Берем и пишем простой незамысловатый класс:

public class EventBroker { private MultiDictionary<string, Delegate> subscriptions = new MultiDictionary<string, Delegate>(true); public void Publish<T>(string name, object sender, T args) { foreach (var h in subscriptions[name]) h.DynamicInvoke(sender, args); } public void Subscribe<T>(string name, Delegate handler) { subscriptions.Add(name, handler); } }

Можно пошаманить над потокобезопасностью (я бы сюда инстинктивно воткнул ReaderWriterLockSlim) и т.п. но суть от этого не изменится. Получили мы брокер, который может заменеджить подписки на события. Конечно никакого QoS вы тут не получите, и всю логику связанную с выборками событий придется писать ручками, но уже есть некоторые подвижки – например, включив в качестве классификатора name, мы создали ситуацию в которой один класс может подписать обработчик на несколько эвентов одновременно.

Игрок больше не вывешивает события вообще.

public class FootballPlayer { private readonly EventBroker broker; public string Name { get; set; } public FootballPlayer(EventBroker broker) { this.broker = broker; } public void Injured() { broker.Publish("LeavingField", this, new PlayerInjuredEventArgs()); } public void SentOff() { broker.Publish("LeavingField", this, new PlayerSentOffEventArgs()); } }

Теперь тренер подписывается через брокер:

public class FootballCoach { private readonly EventBroker broker; public FootballCoach(EventBroker broker) { this.broker = broker; } public void Watch(FootballPlayer player) { broker.Subscribe<EventArgs>("LeavingField", new EventHandler(PlayerIsLeavingField)); } public void PlayerIsLeavingField(object sender, EventArgs args) { Console.WriteLine("Where are you going, {0}?", (sender as FootballPlayer).Name); } }

Здесь мы надеемся на полиморфность, связанную с тем что по канону все наследуют аргументы от EventArgs. Сильное типизирование тут не критично т.к. всегда можно делать приведение типов. Вот как все это будет выглядеть:

var uc = new UnityContainer(); uc.RegisterType<EventBroker>( new ContainerControlledLifetimeManager()); var p = uc.Resolve<FootballPlayer>(); p.Name = "Arshavin"; var c = uc.Resolve<FootballCoach>(); c.Watch(p); p.Injured(); p.SentOff(); 

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

В примере выше, брокер зарегистрирован в контейнере как singleton, так что и игрок и тренер получат одну и ту же копию. Тут я на самом делаю не совсем тонкий намек на то, что в статических сценариях, когда известно кто на что подписывается, подписки можно описывать декларативно, т.е.:

public class FootballCoach { [SubscribesTo("PlayerIsLeaving")] public void PlayerIsLeavingField(object sender, EventArgs args) { Console.WriteLine("Where are you going, {0}?", (sender as FootballPlayer).Name); } } 

На то как это делается можно будет посмотреть в следующей части этого поста, а для тех кому не терпися, советую посмотреть сюда. Информация наверное немного устарела, но сам принцип думаю понятен.

Промежуточное заключение

Решение, приведенное здесь, не является конечным по ряду причин. Во-первых, как-то это некошерно иметь явную связь компонентов с брокером – получается что его нужно пробрасывать в каждый из классов, и в этих классах явно использовать. Эта проблема, как мы увидим в следующей части, вполне просто решается.

Вторая проблема, о которой мы кажется уже говорили, заключается в том, что описание какой-то логики в обработке событий сейчас ограничено одним критерием – строковым литералом который работает чем-то вроде “классификатора”. Ограничивать логику подобными методами – глупо, особенно в связи с присутствием такого мощного инструмента как LINQ. (Думаю, намек понят.)

Tags:

Hubs:

.NET