MVVM Light and PRISM offer messenger to implement event system.

the approximate interface looks like the following one:

interface Messanger
    void Subscribe<TMessageParam>(Action<TMessageParam> action);
    void Unsubscribe<TMessageParam>(Action<TMessageParam> action);
    void Unsubscribe<TMessageParam>(objec actionOwner);
    void Notify<TMessageParam>(TMessageParam param);

Now this model seems beneficial comparing to classic .net events. It works well with Dependency Injection. Actions are stored as weak references so memory leaks are avioded and unsubscribe is not a must. The only annoyance is the need to declare new TMessageParam for each specific message. But everything comes at a cost. And what I'm really worried about is that I see no shortcomings of this approach.

Has anoyne the experience of some troubles with this design pattern?

We tried it and the most unpleasant thing with messages is their implicitness from the point of view of interface. Messages contrary to Events are not exposed explicitly in the interface so additional documentation must be provided.
As Laurent said below very loose coupling comes at a cost of vagueness.

2 Answers 2


One of the native .NET event's attributes is that it's immutable, which makes their access locklessly thread-safe. I'm guessing the same can't be said of this implementation you're referring to, though it may handle the locks under the covers for you so at least you don't have to. Alternatively it may have it's own form of immutable access (is the interface implemented on a value type?) but doing something of that nature is quite tricky in C# which is why events have always had language level support.

Other than that, there may be performance differences between the two but I can't say for certain one way or the other, and further there is the fact of the syntax which is not available in your mentioned approach.

  • The HolyWar began in our team.One part offers an isolation when each concerned class receives some service at constraction. This service contains classic events to provide intercommunications between classes.Their main argument is the disability to send and subscribe to events class doesn't need.I insist on using the messenger with specific events.Isolation can be achieved by clustering the events and moving these clusters to separate assemblies. But frankly speaking I see no sin leaving all the events in one assembly. I think app-wide messaging does't break the separation of concerns. Commented Nov 15, 2012 at 14:43
  • @voroninp I'm not certain I understand some of what you're saying here, but why are you insisting some events use the messenger? Especially since you mention services here I'm guessing you're working in a multi-threaded context, in which case I would strongly suggest you stick with the native .NET events for the thread-safety they afford you. Otherwise be super careful that you have appropriate locking mechanisms in your subscribe/unsubscribe/notify methods. Commented Nov 15, 2012 at 23:59
  • Multithreading is the next stop. We have WinForms app with bad, really bad architecture: everything that could be coupled is coupled. For example one form can subscribe other's form method to the event of the 3d form. No we are cutting these dependencies throwing specific events to IAppContext. Later we will split it. I like Messenger for the ease of introducing new msg types, for filtering by hierarchy level and for weak references. Commented Nov 16, 2012 at 13:13

The major disadvantage of messaging-based systems is that it is less easy to understand what's going on. It can be tougher to debug what's happening than in an event based system, exactly because the messaging system is more loosely coupled. It's the same type of issue that comes with advanced systems like Rx (Reactive extensions).

  • Yes, I read this warning at galasoft.ch/mvvm We can trace all the messages senders and recipients more easily with Messenger. So it can be a mitigation tosome extent. Commented Nov 17, 2012 at 9:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.