EventAggregator vs CompositeCommand

前端 未结 2 863
慢半拍i
慢半拍i 2021-02-05 13:41

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

相关标签:
2条回答
  • 2021-02-05 14:16

    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.

    0 讨论(0)
  • 2021-02-05 14:30

    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.

    0 讨论(0)
提交回复
热议问题