EventAggregator vs CompositeCommand

Question

I worked my way through the Prism guidance and think I got a grasp of most of their communication vehicles.

Commanding is very straightforward, so it is clear that the DelegateCommand will be used just to connect the View with its Model.

It is somewhat less clear, when it comes to cross Module Communication, specifically when to use EventAggregation over Composite Commands.

The practical effect is the same e.g.

• You publish an event -> all subscribers receive notice and execute code in response
• You execute a composite command -> all registered commands get executed and with it their attached code

Both work along the lines of "fire and forget", that is they don't care about any responses from their subscribers after firing the event/executing the commands.

I have trouble seeing a practical difference in usage although I understand that the implementation of both (under the hood) is very different.

So should we think of what it actually means - Event? Is that when something happens (an event occurs)? Something the user did not directly request like a "web request completed"?

And Command? Does that mean a user clicked something and thus issued a command to our application, requesting a service directly?

Is that it? Or are there other ways to determine when to use one of these communication vehicles over the other. The guidance, although one of the best documentations I read, gives no specific explanation.

So I hope people involved in/using Prism can help in shedding some light on this.

Czardom

I agree with you, I have Prism's 4 vs. pdf comes with prism. Its looks well but this compositecommand section not offer us right things. It says give the datacontext on codebehind. I can't beleive that people coded prism prepared this docs. Thanks for asking. – Citadel

Answer 1

There are two primary differences between these two.

1. CanExecute for Commands. A Command can say whether or not it is valid for execution by calling Command.RaiseCanExecuteChanged() and having its CanExecute delegate return false. If you consider the case of a "Save All" CompositeCommand compositing several "Save" commands, but one of the commands saying that it can't execute, the Save All button will automatically disable (nice!).
2. EventAggregator is a Messaging pattern and Commands are a Commanding pattern. Although CompositeCommands are not explicitly a UI pattern, it is implicitly so (generally they are hooked up to an input action, like a Button click). EventAggregator is not this way - any part of the application effectively raise an EventAggregator event: background processes, ViewModels, etc. It is a brokered avenue for messaging across your application with support for things like filtering, background thread execution, etc.

Hope this helps explain the differences. It's more difficult to say when to use each, but generally I use the rule of thumb that if it's user interaction that raises the event, use a command for anything else, use EventAggregator.

Hope this helps.

Judge

Thanks, that was what I thought intuitively, but its nice to have this assumption confirmed. – Czardom

Answer 2

Additionally, there is one more important difference: With the current implementation, an event from the EventAggregator is asynchronous, while the CompositeCommand is synchronous.

If you want to implement something like "notify that event X happened; do something that relies on the event handlers for event X to have executed", you either have to do something like Application.DoEvents() or use CompositeCommands.

Cardamom