Application Patterns and Tips : Use an Event Broker

An event broker is merely an object that acts as middleman for any number of events from any objects to any other object. In a way, this is taking the Observer Pattern  even further.

Here’s a simple event broker implementation:

public class EventBroker
{
    Dictionary<string, List<Delegate>> _subscriptions =
                          new Dictionary<string, List<Delegate>>();

    public void Register(string eventId, Delegate method)
    {
        //associate an event handler for an eventId
        List<Delegate> delegates = null;
        if (!_subscriptions.TryGetValue(eventId, out delegates))
        {
            delegates = new List<Delegate>();
            _subscriptions[eventId] = delegates;
        }
        delegates.Add(method);
    }

    public void Unregister(string eventId, Delegate method)
    {
        //unassociate a specific event handler method for the eventId
        List<Delegate> delegates = null;
        if (_subscriptions.TryGetValue(eventId, out delegates))
        {
            delegates.Remove(method);
            if (delegates.Count == 0)
            {
                _subscriptions.Remove(eventId);
            }
        }
    }

    public void OnEvent(string eventId, params object[] args)
    {
        //call all event handlers for the given eventId
        List<Delegate> delegates = null;
        if (_subscriptions.TryGetValue(eventId, out delegates))
        {
            foreach (Delegate del in delegates)
            {
                if (del.Method != null)
                {
                    if (del.Target != null)
                    {
                        del.DynamicInvoke(args);
                    }
                }
            }
        }
    }
}

					  

Usage is very simple: Rather than raising normal .NET events, just call the appropriate methods on the EventBroker. The project contains three user controls: One of them raises the event and the other two listen for it. A form owns the event broker and ties everything together, as the following partial code example shows:

public partial class Form1 : Form
{
    //a single event broker to tie all controls together
    EventBroker _broker = new EventBroker();

    public Form1()
    {
        InitializeComponent();

        myControl11.SetEventBroker(_broker);
        myControl21.SetEventBroker(_broker);
        myControl31.SetEventBroker(_broker);
    }
}
public partial class MyControl1 : UserControl
{
    EventBroker _broker;

    public MyControl1()
    {
        InitializeComponent();
    }

    public void SetEventBroker(EventBroker broker)
    {
        _broker = broker;
    }

    //when user clicks button, fire the global event
    private void buttonTrigger_Click(object sender, EventArgs e)
    {
        if (_broker != null)
        {
            _broker.OnEvent("MyEvent");
        }
    }
}

public partial class MyControl2 : UserControl
{
    EventBroker _broker;

    public MyControl2()
    {
        InitializeComponent();
    }

    public void SetEventBroker(EventBroker broker)
    {
        _broker = broker;
        _broker.Register("MyEvent", new MethodInvoker(OnMyEvent));
    }

    private void OnMyEvent()
    {
        labelResult.Text = "Event triggered!";
    }
}
//MyControl3 is the same as MyControl2

					  

See the EventBroker sample for the full source.

Using this method gives you a few advantages:

• Because strings are used, any component can publish or subscribe to any event without having to add a reference to a strongly typed object.

• Because no component knows anything about the origin or destination of events, it is trivial to add or remove components with breaking dependencies.

Note

This method is most appropriate for global events that you need to communicate across the entire application, and passing objects around complicated code hierarchies just to listen for events is not worth the headache and maintenance problems that are entailed. For more local events, you should definitely just use the normal .NET event pattern.