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 ?
It’s interesting to have multiple components which have separated responsibility. It is clearly separated, more maintainable and reduce coupling.
Each part of the architecture are separated. Now they need to communicate. What’s better than an event ?
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.
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.