Event-driven architecture

This post will not debate on the benifits of this kind of architecture. We will discuss performances …

What is an event ?

A source will raise an event to indicate, to anyone who’d care to listen, that something happens. A destination will receive this event and act accordingly.

Why choosing an event driven architecture ?

Responsibility

It’s interesting to have multiple components which have separated responsibility. It is clearly separated, more maintainable and reduce coupling.

Simplification

Each part of the architecture are separated. Now they need to communicate. What’s better than an event ?

Power tools

I have tested the EventAggregator pattern for two reasons.

  • EventAggregator can register events in “weak events” format. Weak events are perfect to prevent memory leaks.
  • It is integrated to Prism and can perfectly be injected in our classes.

Our test architecture

Layer 1 will discuss to layer 2 and layer2 will discuss with inner layer 2. We will test direct method call and also event call. We will monitor class creation and call.

As you can see, there is 100 measures for each method. For clarity, i have remove the stopwatches.

Results

First number is ticks and second number is milliseconds. I have also removed 95% of the values due to similarity.

We can conclude two things :

  • First creation and first execution take more time than the others.
  • There is a BIG difference between events through EventAggregator and direct call. This difference is not important in this program but imagine a multi-panel program…

You will find the demo solution here : EventOrNot.zip it contains a little prism module and a “non-event” class hierarchy.

Sharing time :Share on LinkedIn0Tweet about this on TwitterShare on Google+0Email this to someoneShare on Facebook0

1 Response

  1. Olivier Pons says:

    Windows is an event-driven architecture. For some cases it gives far more headaches than a classical “wait then act” architecture.

    Event-driven = asynchronous. This often leads to nice user feedback.
    But this gives headaches to developpers and often comes to un-maintanable code.

    The best example is about IP servers (thus including web servers). Microsoft tried to do TCP / UDP event-driven architecture to integrate closely with its native system.

    http://msdn.microsoft.com/en-us/library/windows/desktop/aa365198(v=vs.85).aspx

    This is called IO Completion port. I’ve worked on that for almost one year, and the result was really powerful but the code was totally un-maintanable (and IO Completion is so close to the system that I’ve had countless BSOD).

    So event-driven architecture *may* be sometimes usefull, but from my experience, it almost always brings to un-maintanable code. This is just a new way of thinking, that’s why when you discover it you say “hey it’s genius”. But in the long run you’ll drop that kind of architecture, believe me 😉

Leave a Reply

Your email address will not be published. Required fields are marked *