Jan 9, 2011 at 3:53 PM
Edited Jan 9, 2011 at 3:58 PM
Caliburn.Micro does not need an implementation of ICommand because it has Actions which are superior to commands in every way :) Have a read through these two articles:
Actions are what replaced the ReflectiveCommand implementation from the BYOMF. ReflectiveCommand was the precursor to Caliburn's action implementation some 4-5 years ago.
Many of the changes made in Caliburn.Micro since the simple demo from Mix were made for one or more of the following reasons:
a. To bring greater compatability with Caliburn.
b. To add a few more features that make it vastly more reusable
Most of the changes in the ViewModelBinder relate to the second reason (though that typically means they relate to the first as well).
If you read through the articles on actions and compare their features to ICommand, you will see why the change was made. Remember with ICommand you can:
1. Only bind to certain controls such as Button, and it can only be triggered by a single, specific event. ie Button.Click
2. Have a CanExecute method that can take a single parameter.
3. Have an Execute method that can take a single parameter.
4. Without conventions, still requires wastefull boiler-plate code.
But with actions you can:
1. Attach to any event on any control.
2. Bind directly to the VM method without having to write boiler-plate glue code.
3. Have a "CanExecute" method or property (and trigger guard poroperty eval with basic INPC).
4. Pass any number of parameters, which can be resolved via databinding, literal values or special values such as $dataContext, $eventArgs and $source.
5. Changes in parameters automatically trigger the guard evaluation. (Not so with ICommand).
6. Execute coroutines
7. Actions bubble, allowing elegant solutions to some complex interactions.
8. Are built on top of System.Windows.Interactivity, so they can be triggered not only by events, but by literally anything.
9. Have a terser, syntax than ICommand via Message.Attach with varying levels of specification vs. convention allowed.
You can read the overview here
Additionally, commands can be built on top of Actions if needed. Since an Action is just a method on a class, a class with only one method becomes a command. Any commands you build on top of Actions inherit all the features of Actions which is better than
the platform implementation. The current use of ICommand by developers for everything is a warping of the original intent and pattern. By using actions, the original intent of commands can be restored. What I mean by that is that in CM, if you choose to use
a command, you are doing it because you really want a command, not just a binding to a VM method.