Commands as XAML Resources

I’m watching Nikhil Kothari’s talk at MIX 2010 while I write. As with all things Nikhil, you owe it to yourself to take a look.
The talk is nominally about developing with WCF RIA Services. It’s really about programming style. Most RIA Services demos are 100% drag-and-drop. You might think that’s the only way or the preferred way to write a RIA Services application.
Not so!  … and Nikhil is determined to show a different path. A standing ovation from me for bucking that trend … while keeping it all accessible to a general development audience.
I particularly liked the moment around the 31st minute when he uses SketchFlow to show how the View relates to a ViewModel.
Scoot ahead to 35:40 and you’ll find Nikhil wiring ViewModel actions to View buttons via Commands that he’s instantiated as resources in the View.
I’m intrigued by this approach even if I’m not completely sold on it.

The Problem

Silverlight lacks the means to directly bind view events (e.g., button clicks) to ViewModel actions (e.g., “Load Books”). That omission has spurred a variety of solutions: event handlers in code-behind, ViewModel commands wired by attached behaviors, and auto-wire-by-convention (Caliburn-style) to name a few.
Nikhil has found another way to do it. We can leverage data binding and declare the hook-up in XAML using a simple resource rather than the more obscure behavior. It is quite seductive. Let me elaborate.

Button Binding

The button has a Command property which can be bound to an implementation of ICommand.
In MVVM we strive to bind the View to members of the ViewModel. It seems natural for the ViewModel to expose ICommand implementations that we can bind to buttons in the View. I’ve done this myself … I hate to admit.
Picking up on Nikhil’s example, our BookViewModel could present a “LoadBooksCommand” property that delivers an ICommand wrapper around the VM’s private “CanLoadBooks” and “LoadBooks” methods.
To support this we write code in the ViewModel like so:

    private ICommand _loadBooksCommand = new Command(LoadBooks, CanLoadBooks);
    public ICommand LoadBooksCommand { get { return _loadBooksCommand; } } 

Yuck. The ViewModel author is interested in “LoadBooks” and “CanLoadBooks”. These are the meat of the matter.
The ICommand is a View artifact that has crept into the ViewModel. The Command(…) isn’t even an instance of a .NET class; we have to get it as a helper from some framework ... Prism perhaps. The whole business is distracting kruft and a PITA.
Many of us just put up with it, writing those command pairs over and over.
Nikhil says “Let’s not pollute the ViewModel this way. Let’s refactor the Command back to the view where it belongs”. Our ViewModel will expose “CanLoadBooks” and “LoadBook”s publically just as we would any bindable property. No more ICommand nonsense.

Command Resources

In his SilverlightFx framework he’s defined a “Command” class that we can instantiate in XAML.
We create Command instances as resources in our view as follows:

    <fx:Command x:Key=”loadCommand” Target=”{Binding}” Method=”LoadBooks” />

Notice that the target is the default binding which will be the ViewModel and the Method name corresponds to the method of that name in the ViewModel (I’m guessing he can infer the CanLoadBooks method as well).
Finally, we bind the “loadButton” Command property to the “loadCommand” resource. In the video, Nikhil uses the Cider designer for this purpose (so much for “no drag-and-drop”). You might prefer to tweak the XAML yourself:

    <Button x:Name=”loadButton” Command=”{StaticResource loadCommand}" ...  />

What’s Not To Like?

I guess it’s ok. Nikhil is making the better of a bad situation, namely, that we cannot yet bind View events to ViewModel methods.
We require a trick shot. We bank the binding cue ball from the button’s Command property off of a static resource at the top of the XAML file and into the ViewModel “LoadBooks” hole. I am not happy about that. I’d prefer to bind the button directly to my ViewModel. On the other hand, I dislike the ICommand crap in my ViewModel. If I must choose between the two, I’m reluctantly inclined toward Nikhil’s approach.
Of course they both breakdown when you need to wire a ViewModel method to anything other than a button Command property. What do you do for the SelectionChanged event of a ComboBox? You can’t bind to that as you can “Button.Command”. You’ll have to reach for a different trick – an attached property perhaps – to do what is essentially the same thing.

Bind By Convention

That’s why I’m increasingly enamored of Rob Eisenberg’s “bind-by-convention” approach which he showed at MIX. I can write

  <Button x:Name=”LoadBooks” />

and Rob’s little framework will both find and wire up my ViewModel’s “LoadBooks” and “CanLoadBooks” methods.
If my ComboBox looks like this:

 <ComboBox x:Name=”Books” />

and if my ViewModel has "Books", "SelectedBook" and "BooksChanged" methods, he'll bind the ComboBox's ItemsSource, SelectedItem and SelectionChanged events for me.
There’s no fuss, no muss whether I’m binding Buttons, ListBoxes, TextBoxes, whatever. And I can always go old-school when the naming conventions fail me. Pretty sweet.
A minor downside with Rob’s approach is the lack of tooling support. Intellisense doesn’t kick in when I’m setting a control’s Name property. I can live with that … especially because his full framework comes with diagnostics that tell me which expected bindings are missing at runtime.

Summing Up

I’m all too used to the ICommand-in-ViewModel and I know I don’t love that. I have a feeling that Nikhil’s Command Resource is a better way. It’s certainly more elegant.
Bind-by-convention is the most appealing choice. But I’ll withhold final judgment until I have more experience with it.
You’ll want to watch Nikhil’s talk in any case to get a more rounded view of your choices. He ranges over more ground than commanding … commanding is perhaps 10 minutes of a one hour talk. Check it out.

Comments on this post are closed.