Introduction
The traditional way of connecting a piece of user interface to some logic has been through events. The canonical example is a button – when clicked, some action is undertaken, hopefully accomplishing some goal the user has intended. Although WPF supports this model completely (as other UI frameworks do), it has its drawbacks:
The event handler is part of the "code behind" where the UI is declared, typically a window or a user control. This makes it difficult to call from other objects that may want to invoke the same logic.
The aforementioned button may disappear and be replaced by (say) a menu item. This would require the event hooking code to potentially change. What if we wanted both a button and a menu item?
An action may not be allowed at a certain state – the button (or whatever) needs to be disabled or enabled at the right time. This adds management overhead to the developer – the need to track state and change it for all UI elements that invoke the same functionality.
An...
