What happened to ReflectiveCommand?

Jan 9, 2011 at 1:33 PM

Hi Rob,

As far as I understood from MVVM Study – Segue - Introducing Caliburn.Micro Caliburn Micro was somewhat related to Mix10's Build Your Own MVVM Framework (kinda cousin or so). Recently I was reading some text that mentions the need to have a custom implementations of ICommand. I remember BYOMF has some sort of custom ICommand implementation so I jump to Caliburn Micro and found... none. What happened to ReflectiveCommand? I open ViewModelBinder.cs on both projects and noticed a lot of changes:

  • BindProperties is still there although the implementation changed a lot
  • BindCommands is missing and apparently was replaced by BindActions

"If Rob did such a big change, he must have very good reasons" I said to myself. But what are those reasons? I tryed to find some answer in the series Caliburn.Micro Soup to Nuts, on the project Documentation and on this forum. I found none.

Next week I'll be arguing with some co-worker at coffee time "My MVVM framework is better than yours" style and I wouldn't know what to say when they throw the accusation "Your MVVM framework doesn't implement ICommand". So please Rob, can you point me to some discussion that explains the whys of this change?


Tiago Freitas Leal

Jan 9, 2011 at 4:53 PM
Edited Jan 9, 2011 at 4: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.


Jan 10, 2011 at 12:13 AM

Hi Rob,

This is a very complete analysis of the question. I guess I'll win my coffee break argument :)


Tiago Freitas Leal

Aug 22, 2013 at 10:18 PM
How about putting this explanation in the documentation for Actions? ;)