I was asked once what Delegate Commands are. And I stumbled J. So finally decided to jot down this phenomena.
Simply put in MSDN terms, Commands are a way to handle user interface (UI) actions. They are a loosely coupled way to bind the UI to the logic that performs the action.
Where would these Commands apply then practically, you think? – In composite applications we have design patterns such as Model-View-Presenter (MVP), Model-View-Controller (MVC), and Model-View-ViewModel (MVVM). Because these design patterns are normally used to separate the UI layout and code/logic. Taking example of WPF, the presenter or controller handles commands outside the WPF logical tree. To learn more about trees, visit this url http://msdn.microsoft.com/en-us/library/ms753391.aspx.
WPF routed commands deliver objects or messages within the tree and even require a command handler in the code behind to access them. But with Composite Application Library we get two commands that can be routed outside the WPF logical tree and do not require the handlers in code behind. These commands are DelegateCommand and CompositeCommand. These commands are custom implementations of ICommand interface defined by WPF and have their own routing mechanism to communicate with objects outside the logical tree.
DelegateCommand: it allows delegation of invoking a target handling method.
CompositeCommand: it has multiple child commands. Is better used in scenarios where you have a view with multiple rows having their own submit or delete button functionality and you would prefer running a selected event on the rows in one go.
My favorite question on commands would be: – (taken AS IS from MSDN)
Why are WPF routed commands not used?
WPF routed commands have a number of limitations. They are coupled to elements in the logical tree because they use routed events to deliver the command messages. This means you cannot directly connect a separate class, such as a presentation model, presenter, or controller, to be the direct command handler. The view would have to be the routed command handler, and it would have to forward the call to the presenter or controller through a method call or event. Additionally, the command handler that the routed event is delivered to is determined by the current focus in the UI. This works fine if the command handler is at the window level, because the window is always in the focus tree of the currently focused element, so it gets called for command messages. However, it does not work for child views who have their own command handlers unless they have the focus at the time. Finally, only one command handler is ever consulted with routed commands. After one command handler is invoked (for CanExecute or Execute), no other handlers are consulted, even if they are in the focus tree of the focused element. For scenarios where multiple views (or their presenters) need to handle the command, there is no decoupled way to address it with routed commands.
