Commands vs Behaviors in MVVM

468 views
Skip to first unread message

Brian Noyes

unread,
Jun 15, 2010, 12:19:23 PM6/15/10
to wpf-di...@googlegroups.com

Hi all,

I think some of you know I worked closely with the p&p team on Prism 1, remained an advisor for Prism 2, and am now working closely with the team again as a contractor for Prism 4 (aligning versions like everyone else). I know many of you have competing frameworks and don’t want to get into a debate of what is wrong with Prism and how your frameworks are better. I’ve studied many of those other frameworks and see the value in the way they do things.

 

One thing we are discussing is whether to use commands at all or to just use behaviors everywhere. Even though they finally added commands in SL 4, the fact is that they still only cover a small subset of the communications you need between a view and a view model, so you usually have to rely on behaviors for the everything other than button/hyperlink/menu clicks. So it raises the question:

 

If you can also easily handle those cases with behaviors, why bother with commands? They require you to understand and mix two concepts and coding patterns, whereas behaviors can pretty much address any scenario, and consistency is important as well.

 

So we are leaning towards just using behaviors everywhere that we used to use delegate commands.

 

Thoughts on this? Vigorous defense of commands over behaviors in the places where they are an option?

 

Thanks

Brian

 

-----------------------------------------
Brian Noyes
Chief Architect, IDesign Inc
Microsoft Regional Director / MVP
http://www.idesign.net
+1 703-447-3712
-----------------------------------------

 

Sacha Barber

unread,
Jun 15, 2010, 12:39:55 PM6/15/10
to wpf-di...@googlegroups.com
I find with an EventToCommand (MouseDown to bound Command say) and also having Command support I can do everything I want.

--
Sacha Barber
sacha....@gmail.com

Karl Shifflett

unread,
Jun 15, 2010, 12:51:45 PM6/15/10
to wpf-di...@googlegroups.com, Mark Boulter

Brian,

 

Like others, I’ve been feeling this wind blowing for a while now.

 

I think about what we give up:

 

It’s hard to beat the CanExecute feature of the CommandManager.  When used properly, it simplifies WPF programming.  I’ve asked the WPF Team a more than a few times to either unseal CommandManager and allow overriding of a method that would allow developers to throttle RequerySuggested, or provide the ability for a command to specify throttling for RequerySuggested.  For example, “only call CanExecute on focus changed.” 

 

The current Cider and Blend Designer tooling both support wiring up commands.  Cider does not have support for adding behaviors using drag and drop.

 

Enter, Silverlight.  I agree with the blowing wind but, I still want automatic CanExecute and UIElement disabling when the behavior can’t execute.  I’ve thought about writing a service that would work in WPF & SL that does the notification.  Commands could register with the service, maybe the behaviors could too.  I hope that what Prism 4 delivers works in WPF & Silverlight.

 

If you proceed with this, please have P&P send a Partner Request to the Cider Team to ensure that they add support for the Asset Library and drag and drop behaviors out of the box.  I’ve been thinking about writing an add-in that does this in VS 2010.  I just need  a few days of free time to do it.

 

Currently the Blend behaviors don’t pass payloads too well, custom behaviors can do anything.  Comamnds have the awesome CommandParameter for passing context to the command.  Behaviors need to expose a way to pass a payload.

 

I agree that Behaviors offer developers the opportunity to write less glue code just to execute a method.  I think about my current viewmodels only publically exposing a few properties and a constructor.  Now, they would also be exposing methods.  Just thinking out loud.

 

Chew the meat, spit out the bones,

 

Karl

Bill Kempf

unread,
Jun 15, 2010, 1:09:35 PM6/15/10
to wpf-di...@googlegroups.com
I honestly don't think Behaviors can, much less should, replace
commands. Commands are an abstraction. They combine some abstract
operation with a mechanism to query whether or not that operation
currently is available to be run. The "can it execute" part is key.
Any solution that failed to include that would be flawed, and not a
valid replacement. However, the abstraction is just as important. This
abstraction isn't tied to anything. Not only does this mean it's
framework neutral. In theory, ICommand could be used not only in
WPF/SL, but also in WinForms, in console applications, even in non-UI
scenarios entirely. Hows that for being radical? ;) Further, because
it's abstracted, I can utilize the abstraction from multiple places.
Three buttons, two menus, four keyboard accelerators, and a Baboon in
a palm tree could all be tied to the same command. You're not going to
get that out of a Behavior by itself.

No, the answer in Silverlight isn't to abandon commands, but rather to
FINALLY implement completely. The next version of SL needs to bring
commands up to the level that exists in WPF.

Then we could use some nice Behaviors that help us to bridge some
command/event gaps. ;)

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.

Laurent Bugnion

unread,
Jun 15, 2010, 1:08:23 PM6/15/10
to wpf-di...@googlegroups.com

Hey Brian,

 

The main reason why I still advise my users to use the Command property on a ButtonBase rather than using EventToCommand (or InvokeCommand or another behavior) everywhere: The XAML syntax for behaviors is annoying to write by hand. Granted, I don’t spend a lot of time adding behaviors manually (that’s what Blend is for), but I know that not all of them do. The Command syntax is more straightforward.

 

A compromise would be to offer an alternative syntax with an attached property. I hear that Blend 4 is better with attached properties than it used to be, but I didn’t have time to investigate. We would need to find a good syntax to define the event name and the binding to the command / commandparameter.

 

If syntax is not an issue, I can imagine that some users might be put off by having to add an external object just to execute a command. There might be a perception that the Command property is faster to execute than EventToCommand for example.

 

Nikhil Kothari has an interesting alternative in his Silverlight FX framework where he can bind an event directly to a method on the VM. This avoids having to declare commands. Eventually I think that this is what we should have in the .NET framework. Having to resort to the third party ICommand implementation (either RelayCommand/DelegateCommand/etc… or custom built command classes) is annoying and should go away. I mentioned this to Anders Helsjberg when we were both in Belgium this spring, and he was apparently aware of the issue. I hope we see that coming soon (I know that Nikhil is pushing that within MSFT).

 

Cheers,

Laurent

Josh Smith

unread,
Jun 15, 2010, 1:35:44 PM6/15/10
to wpf-di...@googlegroups.com
Behaviors are great, if you use Blend.  Otherwise they're not so great, for simple things like telling a button what to do when clicked.  Who wants to type all that XAML, just to avoid using commands?  Not me.  To be honest, I rarely find the need to use ICommands for anything other than ButtonBase clicks.  Maybe I just lack imagination. :)

Josh

Laurent Bugnion

unread,
Jun 15, 2010, 1:45:19 PM6/15/10
to wpf-di...@googlegroups.com, Mark Boulter

A note regarding CanExecute: My EventToCommand does optionally disable the attached object if the command is disabled (and of course if the element can be disabled…). This action is optional, because it just does not make sense to always disable a control for every command. For example, disabling a control for a mouseover command often doesn’t make sense. But for the MouseLeftButtonDown of a Grid, for example, you can disable the Grid (and all its children) when the command’s CanExecute returns false.

 

As for the CommandManager, I am a bit unsure that it is really such a loss in Silverlight. Sure I have to raise CanExecuteChanged manually (the RelayCommand has a RaiseCanExecuteChanged method that does this) but on the other hand I have total control on when this should occur. The CommandManager, on the other hand, is a bit too magical for my taste.

 

Anyway, to come back to Brian’s point, by using behaviors instead of the Command property, one is not giving up the disabling of the control, if the behavior is programmed properly and takes care of this.

 

Cheers,

Laurent

Brian Noyes

unread,
Jun 15, 2010, 1:53:39 PM6/15/10
to wpf-di...@googlegroups.com

Thanks for all the inputs. I personally have the same resistance to giving up commands for the same reasons everyone stated.

 

I agree that if you replaced a command with a behavior, that behavior would have to also support enable/disable and parameters. The one the team currently wrote and is using in the MVVM Quickstart supports the enable part as another method you can point to (optionally, like commands) on your view model. It currently does not support parameters, but not sure why it couldn’t.

 

I also have some resistance to making methods on my view model part of the exposed API instead of just properties.

 

Another point of resistance is that if you go with non-Blend behaviors, you limit Blendability, if you go with Blend behaviors, you have to take a dependency on the Blend SDK.

 

But the counter point that keeps coming back up is that it is not like you can often get away with no behaviors, so you will have to deal with all the negative aspects of behaviors already.

 

The real question we are trying to reconcile is “if you are already using behaviors for other things in your UI, what does using commands for those things you can buy you over using a behavior for those as well?” This does assume we are talking about a behavior that lets you point to an execute method, a can execute method, and carry bindable parameters.

 

The main argument I am hearing based on the above is easier syntax for commands. The counter to that would be better consistency, a single concept to master, and less glue (no delegate/relay command definition/hookup required).

Thanks

Brian

Josh Smith

unread,
Jun 15, 2010, 1:59:47 PM6/15/10
to wpf-di...@googlegroups.com
Also, by relying on Behaviors, you're assuming everyone has, or is willing to get/learn/use, Blend.  I doubt that most dev-only shops, especially smaller ones, are interested in that.  Visual Studio is King.

Josh

Bill Kempf

unread,
Jun 15, 2010, 1:59:57 PM6/15/10
to wpf-di...@googlegroups.com
The executable portion and the query are closely tied to each other.
The solution your suggesting, where the Behavior is tied to two
separate methods for exeuction and query, blurs the connection. It
would be quite easy to add a behavior that fails to hook up the query
portion, and trouble will ensue. You can't do that with ICommand,
because there's two concepts are combined into one.

--

Bill Kempf

unread,
Jun 15, 2010, 2:01:52 PM6/15/10
to wpf-di...@googlegroups.com
Visual Studio _should_ work with Behaviors. I think this was a mistake
with the designer in VS2010, one which might be fixed with an
extension, and almost certainly will be fixed in the next version,
when Behaviors are brought into the BCL (hint, hint).

--

Brian Noyes

unread,
Jun 15, 2010, 2:02:58 PM6/15/10
to wpf-di...@googlegroups.com

Not true, Blend SDK, not Blend. It is just an SDK and you can xcopy deploy the DLLs. So yes, you have a dependency, but no more so than if you depend on Prism, or MVVM Light, or Framework X.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith


Sent: Tuesday, June 15, 2010 11:00 AM
To: wpf-di...@googlegroups.com

Bill Kempf

unread,
Jun 15, 2010, 2:05:13 PM6/15/10
to wpf-di...@googlegroups.com
I believe that Josh's point is that VS has no support for Behaviors.
Using Behaviors without designer support is a bit of a non-starter for
many people, as the XAML syntax is more than a tad ugly and verbose.

On Tue, Jun 15, 2010 at 2:02 PM, Brian Noyes
<brian...@softinsight.com> wrote:
> Not true, Blend SDK, not Blend. It is just an SDK and you can xcopy deploy
> the DLLs. So yes, you have a dependency, but no more so than if you depend
> on Prism, or MVVM Light, or Framework X.
>
>
>
> From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
> On Behalf Of Josh Smith
> Sent: Tuesday, June 15, 2010 11:00 AM
>
>
>

--

Brian Noyes

unread,
Jun 15, 2010, 2:06:00 PM6/15/10
to wpf-di...@googlegroups.com
Playing devils advocate here (I am on the fence on this issue)...
The same argument could be made with a Delegate/RelayCommand - you could
fail to hook things up correctly there as well. Counter argument would be
that the command object is in the hands of the view model implementer
where the logic resides so is less likely to be screwed up, whereas the
behavior might be in the hands of a designer who may not even (maybe
should not) know what methods exist on the view model.

I was mainly arguing to stick with commands with the team. Thanks for
giving me some additional arguments to do so.
Brian

-----Original Message-----
From: wpf-di...@googlegroups.com
[mailto:wpf-di...@googlegroups.com] On Behalf Of Bill Kempf
Sent: Tuesday, June 15, 2010 11:00 AM
To: wpf-di...@googlegroups.com

> RelayCommand/DelegateCommand/etc. or custom built command classes) is

Josh Smith

unread,
Jun 15, 2010, 2:06:09 PM6/15/10
to wpf-di...@googlegroups.com
Yeah, that was my point (which I could have made more clearly, sorry).

Brian Noyes

unread,
Jun 15, 2010, 2:06:18 PM6/15/10
to wpf-di...@googlegroups.com
Gotcha.

Bill Kempf

unread,
Jun 15, 2010, 2:14:29 PM6/15/10
to wpf-di...@googlegroups.com
The Delegate/RelayCommand isn't the same. With the Behavior, every
time you want the command behavior you have to connect the operation
and the query. With Delegate/RelayCommand (and for the matter, with
WPF CommandBinding) this is defined once, and the aggregate definition
is then used in multiple places. If your operation is going to be tied
to only one UI component, then using a Behavior isn't a problem. One
that operation is tied to multiple UI components and reused in other
places, then we start to have a problem.

I will say, though, that I've been moving away from
Delegate/RelayCommand in my own code, and relying almost exclusively
on CommandBinding. I do this through a service provided to the
ViewModel that will add the bindings to the View. This allows me to
use "built-in commands" in exactly the same way I use my own commands.

On Tue, Jun 15, 2010 at 2:06 PM, Brian Noyes

Daniel Vaughan

unread,
Jun 15, 2010, 2:31:53 PM6/15/10
to WPF Disciples
Hi Brian,

Behaviours seem a light weight counterpart to me. As has been said,
Commands encapsulate the evaluation and execution logic. I think
moving to just behaviours would not be the right direction, as SL4 now
has commanding. My Calcium framework uses Prism. If you remove
commands, I think a bunch of people will have to reengineer a lot of
code.

Cheers,
Daniel

Brian Noyes

unread,
Jun 15, 2010, 3:06:15 PM6/15/10
to wpf-di...@googlegroups.com
Just to be clear, we definitely would not remove anything. We are just
considering using only behaviors in the Quickstarts and RIs, and maybe
discussing the tradeoffs of commands and behaviors in the docs and
making a recommendation on when/ if to use commands vs behaviors.

Sent from my phone, please forgive typos and brevity

On Jun 15, 2010, at 11:31 AM, Daniel Vaughan <dbva...@gmail.com>
wrote:

Laurent Bugnion

unread,
Jun 15, 2010, 3:31:03 PM6/15/10
to wpf-di...@googlegroups.com

Actually the dependency on Sys.Win.Interactivity.dll is also a good reason not to use a behavior. This is why EventToCommand is in the Extras DLL of MVVM Light, I didn’t want to force the user to add this extra DLL to their application.

Brian Noyes

unread,
Jun 15, 2010, 4:44:44 PM6/15/10
to wpf-di...@googlegroups.com

OK, I’ll bite… J

Why is it harder to reference that assembly than referencing your extras one? I’m sure some of my customers might be more comfortable referencing something produced and supported by Microsoft rather than one from that really smart guy in Switzerland. J

Daniel Vaughan

unread,
Jun 15, 2010, 6:03:47 PM6/15/10
to WPF Disciples
Ok, it sounded like you were debating whether or not Prism would still
support DelegateCommands etc. But, while not removing anyting, it
still sounded like commanding might be excluded in the long run.


On Jun 16, 2:06 am, Brian Noyes <brian.no...@softinsight.com> wrote:
> Just to be clear, we definitely would not remove anything. We are just
> considering using only behaviors in the Quickstarts and RIs, and maybe
> discussing the tradeoffs of commands and behaviors in the docs and
> making a recommendation on when/ if to use commands vs behaviors.
>
> Sent from my phone, please forgive typos and brevity
>
> On Jun 15, 2010, at 11:31 AM, Daniel Vaughan <dbvaug...@gmail.com>

Glenn Block

unread,
Jun 15, 2010, 8:31:53 PM6/15/10
to wpf-di...@googlegroups.com
On the platform side there have been lots of disciussions on moving
away from it long term. One of the reasons we were pushing for markup
extensions in SL was to support a custom ME for calling methods.

--
Sent from my mobile device

Laurent Bugnion

unread,
Jun 16, 2010, 2:01:14 AM6/16/10
to wpf-di...@googlegroups.com
Wow we will have a custom Glenn Block (you said custom ME). Can we add
features to it too?

:)
Laurent

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]

On Behalf Of Glenn Block
Sent: Wednesday, June 16, 2010 2:32 AM
To: wpf-di...@googlegroups.com

Laurent Bugnion

unread,
Jun 16, 2010, 2:05:49 AM6/16/10
to wpf-di...@googlegroups.com

Hey Brian,

 

No no, I meant that if they choose not to use the EventToCommand behavior, but they only want to use the RelayCommand, Messenger and ViewModelBase, they can add a  reference to GalaSoft.MvvmLight.dll only. If they want to use EventToCommand, they need additional reference to GalaSoft.MvvmLight.Extras.dll and Sys.Win.Interactivity.dll.

 

I didn’t want to force them to add a reference to Sys.Win.Interactivity.dll if they don’t explicitly use that feature. Mostly it is because of the bulk added to the download (Sys.Win.Interactivity is added to the XAP file). So I didn’t mean it is harder, just that some are hesitating to use behaviors because of the extra bulk.

 

Does that make more sense?

 

Now who is that really smart guy in Switzerland, I’d love to meet him…

Glenn Block

unread,
Jun 16, 2010, 3:05:45 AM6/16/10
to wpf-di...@googlegroups.com
Lol

Peter O'Hanlon

unread,
Jun 16, 2010, 3:46:36 AM6/16/10
to wpf-di...@googlegroups.com
Are you saying here that the long term vision is to move away from Commanding, or remove Commanding altogether? IMHO this second option would be a bad move and would alienate a lot of people who have invested a lot of time and money in their code only to effectively have it obsoleted for no real reason that I can see. As long as the tooling supports both, then let people use both - I, for one, prefer Commands for click behaviour because they are discrete and easy to code and test in isolation, whereas MEs have required that little bit more infrastructure for testing.
 
Part of the reason here is that people do seem to like POCO, but MEs can put people off because they require a deeper understanding of the subsystem (not true, I know, but it is a perception).

--
Peter O'Hanlon

Sacha Barber

unread,
Jun 16, 2010, 4:13:53 AM6/16/10
to wpf-di...@googlegroups.com
Yeah I would hate to see Commands go away, I see nothing wrong with them. In fact some of the newer blend behaviours give me the creeps, CallMethodAction springs to mind. I do not like that at all. I like Commands they are known quantites and for me are the clear way that the UI talks to the VM. I know where to look. If we allow Views to call methods directly, I for one would not like that. When I hunt through my code so see how the view is doing something, I am generally looking for commands. 

Are we saying any public method is now a candidate too. Not my bag I have to say.

My 2 cents.

I do agree that the Interactivity syntax does produce more XAML, but I can live with it, as if done right is 100% done by a tool, so I should not have to look at the XAML for that part.
--
Sacha Barber
sacha....@gmail.com

Laurent Bugnion

unread,
Jun 16, 2010, 5:17:03 AM6/16/10
to wpf-di...@googlegroups.com

Hey Sacha,

 

Just wondering, why exactly?

 

Let’s say we could have the same CanExecute functionality as with commands now (I am not sure how, but for the argument, let’s just imagine that). What would then be the difference between calling a method directly or calling it through a command?

 

The way I see it:

·         Access from the view could be governed by an attribute setting [ViewBindingAllowed] or something

·         It would make testability better, because invoking commands from unit tests is more cumbersome than calling a method directly

 

I agree with you that the CallMethodAction is not a good way to solve that. IMO introducing reflection here is not a good idea. That said, if it was built in the .NET framework, I would probably prefer it.

 

Curious to hear what your thoughts are about this.

 

Cheers,

Laurent

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Sacha Barber
Sent: Wednesday, June 16, 2010 10:14 AM
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] Commands vs Behaviors in MVVM

 

Yeah I would hate to see Commands go away, I see nothing wrong with them. In fact some of the newer blend behaviours give me the creeps, CallMethodAction springs to mind. I do not like that at all. I like Commands they are known quantites and for me are the clear way that the UI talks to the VM. I know where to look. If we allow Views to call methods directly, I for one would not like that. When I hunt through my code so see how the view is doing something, I am generally looking for commands. 

Sacha Barber

unread,
Jun 16, 2010, 5:30:21 AM6/16/10
to wpf-di...@googlegroups.com
Personally I just like ICommand, as I know where to find all the logic is and what exactly has an impact on what. A big part of that for me is CanExecute and I do realise we are obviously just calling Execute which is a method of course. But I just like the seperation a whole lot better, and I think it keeps the XAML a lot cleaner.

I find it no bother to execute a command in a unit test, its like someCommand.Execute(whatever parameter I like), I fail to see how this is any harder than calling a method.

Generally I am not a massive fan of more polution in my XAML, so I guess as long as whatever ME or Behaviour does not pollute my XAML too much I would be ok with it. 


--
Sacha Barber
sacha....@gmail.com

John Gossman

unread,
Jun 16, 2010, 5:38:36 AM6/16/10
to wpf-di...@googlegroups.com
This is a deep subject and unfortunately a topic that is taking far too long to resolve (I've been looking at Commands and Behaviors since 2003, but coordinating VS, Blend, SL, WPF and BCL is extremely cumbersome even when consensus has been achieved).  In a theoretical computer science sense, Behaviors are the most general (Commands, Templates and even Styles can be seen as special cases of an attached behavior).  This does not make them the simplest thing though. 
I hope people do not shy away from behaviors because they ship as part of the Blend SDK (though I fully expect people will).  The Blend SDK is just a set of assemblies, we named them and designed them to move into lower levels of the system (and I take full responsibility for the communications snafu that led to them not being shipped as part of the WPF and SL SDKs). 
My current thinking is that being able to call methods directly from XAML is a good thing.  It would be ideal if it was clear what methods should be called from XAML and why, but I would rather do this from metadata than from enforcing this by requiring folks to wrap Commands around the methods they want to expose.

Daniel Vaughan

unread,
Jun 16, 2010, 5:39:36 AM6/16/10
to WPF Disciples
I agree with Sacha.
By explicitly placing the logic of the command in a class it achieves
a couple of things:
I feel that it promotes separation of concerns. Wrapping code up into
commands means that model logic is less likely to creep into the view.
It provides the possibility of an interception point for all commands
via through subclassing or through the CommandManager (perhaps
something API modification will allow this in the future).



On Jun 16, 4:30 pm, Sacha Barber <sacha.bar...@gmail.com> wrote:
> Personally I just like ICommand, as I know where to find all the logic is
> and what exactly has an impact on what. A big part of that for me is
> CanExecute and I do realise we are obviously just calling Execute which is a
> method of course. But I just like the seperation a whole lot better, and I
> think it keeps the XAML a lot cleaner.
>
> I find it no bother to execute a command in a unit test, its like
> someCommand.Execute(whatever parameter I like), I fail to see how this is
> any harder than calling a method.
>
> Generally I am not a massive fan of more polution in my XAML, so I guess as
> long as whatever ME or Behaviour does not pollute my XAML too much I would
> be ok with it.
>
> On Wed, Jun 16, 2010 at 10:17 AM, Laurent Bugnion <laur...@galasoft.ch>wrote:
>
>
>
> > Hey Sacha,
>
> > Just wondering, why exactly?
>
> > Let’s say we could have the same CanExecute functionality as with commands
> > now (I am not sure how, but for the argument, let’s just imagine that). What
> > would then be the difference between calling a method directly or calling it
> > through a command?
>
> > The way I see it:
>
> > ·         Access from the view could be governed by an attribute setting
> > [ViewBindingAllowed] or something
>
> > ·         It would make testability better, because invoking commands from
> > unit tests is more cumbersome than calling a method directly
>
> > I agree with you that the CallMethodAction is not a good way to solve that.
> > IMO introducing reflection here is not a good idea. That said, if it was
> > built in the .NET framework, I would probably prefer it.
>
> > Curious to hear what your thoughts are about this.
>
> > Cheers,
>
> > Laurent
>
> > *From:* wpf-di...@googlegroups.com [mailto:
> > wpf-di...@googlegroups.com] *On Behalf Of *Sacha Barber
> > *Sent:* Wednesday, June 16, 2010 10:14 AM
> > *To:* wpf-di...@googlegroups.com
> > *Subject:* Re: [WPF Disciples] Commands vs Behaviors in MVVM
>
> > Yeah I would hate to see Commands go away, I see nothing wrong with them.
> > In fact some of the newer blend behaviours give me the creeps,
> > CallMethodAction springs to mind. I do not like that at all. I like Commands
> > they are known quantites and for me are the clear way that the UI talks to
> > the VM. I know where to look. If we allow Views to call methods directly, I
> > for one would not like that. When I hunt through my code so see how the view
> > is doing something, I am generally looking for commands.
>
> > Are we saying any public method is now a candidate too. Not my bag I have
> > to say.
>
> > My 2 cents.
>
> > I do agree that the Interactivity syntax does produce more XAML, but I can
> > live with it, as if done right is 100% done by a tool, so I should not have
> > to look at the XAML for that part.
>
> > On Wed, Jun 16, 2010 at 8:46 AM, Peter O'Hanlon <pete.ohan...@gmail.com>
> > wrote:
>
> > Are you saying here that the long term vision is to move away from
> > Commanding, or remove Commanding altogether? IMHO this second option would
> > be a bad move and would alienate a lot of people who have invested a lot of
> > time and money in their code only to effectively have it obsoleted for no
> > real reason that I can see. As long as the tooling supports both, then let
> > people use both - I, for one, prefer Commands for click behaviour because
> > they are discrete and easy to code and test in isolation, whereas MEs have
> > required that little bit more infrastructure for testing.
>
> > Part of the reason here is that people do seem to like POCO, but MEs can
> > put people off because they require a deeper understanding of the subsystem
> > (not true, I know, but it is a perception).
>
> > On 16 June 2010 01:31, Glenn Block <glenn.bl...@gmail.com> wrote:
>
> > On the platform side there have been lots of disciussions on moving
> > away from it long term. One of the reasons we were pushing for markup
> > extensions in SL was to support a custom ME for calling methods.
>
> > sacha.bar...@gmail.com
>
> --
> Sacha Barber
> sacha.bar...@gmail.com

John Gossman

unread,
Jun 16, 2010, 5:44:02 AM6/16/10
to wpf-di...@googlegroups.com
Yeah, we need VS to support behaviors.  Karl, I assume this is on the list for next time?

Laurent Bugnion

unread,
Jun 16, 2010, 6:24:26 AM6/16/10
to wpf-di...@googlegroups.com
I agree that myCommand.Execute(param) is not much more complicated than
myViewModel.DoSomething(param) to people who understand how commands work.
However it is an indirection that is not strictly needed.

Just to be clear: I am not interested in promoting another ME or behavior.
What Nikhil and I had been discussing is more along the line of having the
event calling a method in the DataContext directly, without additional
layer. Granted, the syntax would need to allow at least the same capability
than the Command/CommandParameter pair does now. Also, it would need to be
part of the core.

Anyway, thanks for explaining.
Cheers,
Laurent

-----Original Message-----
From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]

Sacha Barber

unread,
Jun 16, 2010, 6:38:31 AM6/16/10
to wpf-di...@googlegroups.com
No worries. Whatever you guys work up, remember less xaml is sometimes more ;-)
--
Sacha Barber
sacha....@gmail.com

Laurent Bugnion

unread,
Jun 16, 2010, 6:40:35 AM6/16/10
to wpf-di...@googlegroups.com

I’ve been bugging various teams about renaming so called Blend-behaviors to something else without the Blend part. That name leads people to think that “oh it’s something for designers”.

 

Cheers,

Laurent

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of John Gossman
Sent: Wednesday, June 16, 2010 11:39 AM
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] Commands vs Behaviors in MVVM

 

This is a deep subject and unfortunately a topic that is taking far too long to resolve (I've been looking at Commands and Behaviors since 2003, but coordinating VS, Blend, SL, WPF and BCL is extremely cumbersome even when consensus has been achieved).  In a theoretical computer science sense, Behaviors are the most general (Commands, Templates and even Styles can be seen as special cases of an attached behavior).  This does not make them the simplest thing though. 

Sacha Barber

unread,
Jun 16, 2010, 6:47:29 AM6/16/10
to wpf-di...@googlegroups.com
Agreed, could not agree more
--
Sacha Barber
sacha....@gmail.com

Peter O'Hanlon

unread,
Jun 16, 2010, 6:52:20 AM6/16/10
to wpf-di...@googlegroups.com
Oh yes. That would be good.
--
Peter O'Hanlon

Laurent Bugnion

unread,
Jun 16, 2010, 7:37:49 AM6/16/10
to wpf-di...@googlegroups.com

Totally agreed.




--
Sacha Barber
sacha....@gmail.com

Glenn Block

unread,
Jun 16, 2010, 8:55:39 AM6/16/10
to wpf-di...@googlegroups.com
I am with Laurent on this. From a TDD perspective it is a lot easier
to just spin up a VM and poke it's members rather than have to mock
out commands.

As far as ME syntax agree today it may be a bit more mysterious but if
it was to become the standard people would use it., IMO.

I doubt we would deprecate commands, but we would probably demphasize
them if we had such a feature. That is unless there was a big push
back.

On the Blend behaviors, we are working on a tighter syntax which Pete
Blois has been pushing for. Something that would be equivalent to ME
from a look and feel perspective.


On 6/16/10, Laurent Bugnion <lau...@galasoft.ch> wrote:
> Hey Sacha,
>
>
>
> Just wondering, why exactly?
>
>
>
> Let's say we could have the same CanExecute functionality as with commands
> now (I am not sure how, but for the argument, let's just imagine that). What
> would then be the difference between calling a method directly or calling it
> through a command?
>
>
>
> The way I see it:
>

> . Access from the view could be governed by an attribute setting
> [ViewBindingAllowed] or something
>
> . It would make testability better, because invoking commands from

>> http://www.idesign.net <http://www.idesign.net/>

Bill Kempf

unread,
Jun 16, 2010, 8:55:49 AM6/16/10
to wpf-di...@googlegroups.com
I think I covered why I think it's a non-starter, but I'll put it in a
bullet list.

1. Unless you find a way for the behavior to be reusable in multiple
places, it's inferior to commands. The only way I can see to do this
is to write a custom behavior every time, which isn't an improvement.

2. Unless the behavior fully encapsulates both execution and query,
it's inferior to commands. The only way I can see to do this makes
point (1) even more important, because if it's not a custom behavior
we've then got a point for human error.

3. Behaviors are not only UI concepts, but WPF/SL concepts. This
limits their reusability in comparison to commands, which are truly
generic abstractions usable anywhere.

4. Without commands you lose the ability to define common operations,
such as cut/copy/paste.

On Wed, Jun 16, 2010 at 5:17 AM, Laurent Bugnion <lau...@galasoft.ch> wrote:
> Hey Sacha,
>
>
>
> Just wondering, why exactly?
>
>
>
> Let’s say we could have the same CanExecute functionality as with commands
> now (I am not sure how, but for the argument, let’s just imagine that). What
> would then be the difference between calling a method directly or calling it
> through a command?
>
>
>
> The way I see it:
>
> ·         Access from the view could be governed by an attribute setting
> [ViewBindingAllowed] or something
>
> ·         It would make testability better, because invoking commands from
> unit tests is more cumbersome than calling a method directly
>
>
>
> I agree with you that the CallMethodAction is not a good way to solve that.
> IMO introducing reflection here is not a good idea. That said, if it was
> built in the .NET framework, I would probably prefer it.
>
>
>
> Curious to hear what your thoughts are about this.
>
>
>
> Cheers,
>
> Laurent
>
>
>
> From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com]
> On Behalf Of Sacha Barber
> Sent: Wednesday, June 16, 2010 10:14 AM
>
>
>

--

Mark Smith

unread,
Jun 16, 2010, 9:04:42 AM6/16/10
to wpf-di...@googlegroups.com
Great list Bill, I'll add three more:

5. Behaviors must be supported by all the tooling (not just Blend). Until then, they will always be considered "part of Blend" and likely avoided by many developers afraid of Blend.
6. The Sys.Win.Interactivity.dll and basic, standardized behaviors must become part of the framework. As mentioned before, keeping them in the Blend SDK just reinforces the message that they are part of Blend.
7. They must be usable in all scenarios - today, AFAIK, it's not possible to associate a behavior inside a Style - so I can't place a behavior directly on a ListBoxItem for example. I haven't tried this recently (i.e. with Blend4 and WPF4), but I hadn't heard anything about it changing.

I'm not opposed to Behaviors replacing commands via either invoking methods directly, or even just providing the shim to execute defined commands from the UI, but I will say that there are places where the RoutedCommand infrastructure is nice - Cut/Copy/Paste is a good one - I just don't see how today's behaviors could replace that without completely.

mark

Glenn Block

unread,
Jun 16, 2010, 9:05:44 AM6/16/10
to wpf-di...@googlegroups.com
On Reusability, many (most?) foiks are using DelegateCommand /
RelayComnand today which simply take lambdas. That's not "reusable'
either.

Why would you see having to author custom behaviors?

Bill Kempf

unread,
Jun 16, 2010, 9:05:53 AM6/16/10
to wpf-di...@googlegroups.com
That sums up where I think the disconnect is from my view point and
what Microsoft seems to be thinking here.

"It would be ideal if it was clear what methods should be called from
XAML and why, but I would rather do this from metadata than from
enforcing this by requiring folks to wrap Commands around the methods
they want to expose."

See, when we're just talking about calling methods, I agree with you.
But I don't see commands in that light. A command is much more than
simply a mechanism to call a method. Sometimes what you want to do is
just call a method. For instance, performing complex logic in response
to a selection change fits this bill. Other times, it's not simply
calling a method. Performing cut/copy/paste, opening/saving a file,
etc. are all richer concepts than just calling a method. These are
specific actions taken by a user in different contexts using different
methods of invocation, all of which need to behave the same no matter
the circumstances surrounding the invocation. Treating these as simple
method calls is NOT the way I would ever treat them. If WPF/SL moved
away from commands, I'd just have to roll my own... and quite frankly,
at that point I'd question the framework designers decisions and
whether or not WPF/SL were the platform for me.

--

Glenn Block

unread,
Jun 16, 2010, 9:08:20 AM6/16/10
to wpf-di...@googlegroups.com
These are good points and issues that will have to at least be
addressed to go down that route.

Peter O'Hanlon

unread,
Jun 16, 2010, 9:13:13 AM6/16/10
to wpf-di...@googlegroups.com
Which part isn't reusable? The RelayCommand/DelegateCommand part, or the lambdas? If it's just the commanding part, then that's not really a problem - they are just infrastructure provided to fit a need to have a concrete class. The actual hook up should be implementation, so can be mocked and tested in isolation.
 
I also don't see why it's easier to fire up a VM and poke its methods than to have a command in place? Bear in mind that we've covered that commanding is more than just firing a method off, it's a lot easier for me to test and ensure that something is protected by CanExecute than have to worry about rolling my own functionality to cover this.

--
Peter O'Hanlon

Bill Kempf

unread,
Jun 16, 2010, 9:14:05 AM6/16/10
to wpf-di...@googlegroups.com
Wrong. It's still reusable. The same command is reused from multiple
places in the UI.

Apart from that, you're pointing out a limitation of specific ICommand
implementations, and not with the larger concept. I'll point out
Cut/Copy/Paste which is reusable in the larger sense. The same command
is used, with different code being executed based on context.

Glenn Block

unread,
Jun 16, 2010, 9:14:51 AM6/16/10
to wpf-di...@googlegroups.com
I think the motivation here is to simplify when all you want to do is
call a method, As far as the cut/copy/paste concerns ie
standard/reusable functiinality that is a different boat. Thought
maybe there is a special ME for that or it still uses ICommands. I am
not sure on that one. These are good points though.

On 6/16/10, Bill Kempf <wek...@gmail.com> wrote:

--

Peter O'Hanlon

unread,
Jun 16, 2010, 9:16:33 AM6/16/10
to wpf-di...@googlegroups.com
I'm all for simplification - as long as I can still have my Commands for when they make the most sense.
--
Peter O'Hanlon

Glenn Block

unread,
Jun 16, 2010, 9:20:34 AM6/16/10
to wpf-di...@googlegroups.com
So let's break this into 2 categories.

Category 1 - What you want to do is invoke a method and have that
enabled / disabled. For these more targetted scenarios something like
CallMethodAction 'could' work.

Category 2 - You want to use Contextually aware reusable / standard
bits of app functiomality like Copy/Paste etc. For these call method
won't work as there is no 'method' on the VM to call.

Is that right? Are there any others?

Glenn

Glenn Block

unread,
Jun 16, 2010, 9:24:33 AM6/16/10
to wpf-di...@googlegroups.com
It is quite possible we can get disconnected, that's why it is good we
have you guys around :-)

On 6/16/10, Bill Kempf <wek...@gmail.com> wrote:

--

Brian Noyes

unread,
Jun 16, 2010, 9:30:06 AM6/16/10
to wpf-di...@googlegroups.com
I agree with the download and memory footprint arguments. Was just making sure there was not another angle there I was not thinking of.

On Tue, Jun 15, 2010 at 11:05 PM, Laurent Bugnion <lau...@galasoft.ch> wrote:

Hey Brian,

 

No no, I meant that if they choose not to use the EventToCommand behavior, but they only want to use the RelayCommand, Messenger and ViewModelBase, they can add a  reference to GalaSoft.MvvmLight.dll only. If they want to use EventToCommand, they need additional reference to GalaSoft.MvvmLight.Extras.dll and Sys.Win.Interactivity.dll.

 

I didn’t want to force them to add a reference to Sys.Win.Interactivity.dll if they don’t explicitly use that feature. Mostly it is because of the bulk added to the download (Sys.Win.Interactivity is added to the XAP file). So I didn’t mean it is harder, just that some are hesitating to use behaviors because of the extra bulk.

 

Does that make more sense?

 

Now who is that really smart guy in Switzerland, I’d love to meet him…

 

Cheers,

Laurent

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Brian Noyes
Sent: Tuesday, June 15, 2010 10:45 PM


To: wpf-di...@googlegroups.com
Subject: RE: [WPF Disciples] Commands vs Behaviors in MVVM

 

OK, I’ll bite… J

Why is it harder to reference that assembly than referencing your extras one? I’m sure some of my customers might be more comfortable referencing something produced and supported by Microsoft rather than one from that really smart guy in Switzerland. J

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Laurent Bugnion
Sent: Tuesday, June 15, 2010 12:31 PM
To: wpf-di...@googlegroups.com
Subject: RE: [WPF Disciples] Commands vs Behaviors in MVVM

 

Actually the dependency on Sys.Win.Interactivity.dll is also a good reason not to use a behavior. This is why EventToCommand is in the Extras DLL of MVVM Light, I didn’t want to force the user to add this extra DLL to their application.

 

Cheers,

Laurent

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Brian Noyes
Sent: Tuesday, June 15, 2010 7:54 PM
To: wpf-di...@googlegroups.com
Subject: RE: [WPF Disciples] Commands vs Behaviors in MVVM

 

Thanks for all the inputs. I personally have the same resistance to giving up commands for the same reasons everyone stated.

 

I agree that if you replaced a command with a behavior, that behavior would have to also support enable/disable and parameters. The one the team currently wrote and is using in the MVVM Quickstart supports the enable part as another method you can point to (optionally, like commands) on your view model. It currently does not support parameters, but not sure why it couldn’t.

 

I also have some resistance to making methods on my view model part of the exposed API instead of just properties.

 

Another point of resistance is that if you go with non-Blend behaviors, you limit Blendability, if you go with Blend behaviors, you have to take a dependency on the Blend SDK.

 

But the counter point that keeps coming back up is that it is not like you can often get away with no behaviors, so you will have to deal with all the negative aspects of behaviors already.

 

The real question we are trying to reconcile is “if you are already using behaviors for other things in your UI, what does using commands for those things you can buy you over using a behavior for those as well?” This does assume we are talking about a behavior that lets you point to an execute method, a can execute method, and carry bindable parameters.

 

The main argument I am hearing based on the above is easier syntax for commands. The counter to that would be better consistency, a single concept to master, and less glue (no delegate/relay command definition/hookup required).

Thanks

Brian

From: wpf-disciples@googlegroups..com [mailto:wpf-di...@googlegroups.com] On Behalf Of Laurent Bugnion
Sent: Tuesday, June 15, 2010 10:08 AM
To: wpf-di...@googlegroups.com
Subject: RE: [WPF Disciples] Commands vs Behaviors in MVVM

 

Hey Brian,

 

The main reason why I still advise my users to use the Command property on a ButtonBase rather than using EventToCommand (or InvokeCommand or another behavior) everywhere: The XAML syntax for behaviors is annoying to write by hand. Granted, I don’t spend a lot of time adding behaviors manually (that’s what Blend is for), but I know that not all of them do. The Command syntax is more straightforward.

 

A compromise would be to offer an alternative syntax with an attached property. I hear that Blend 4 is better with attached properties than it used to be, but I didn’t have time to investigate. We would need to find a good syntax to define the event name and the binding to the command / commandparameter.

 

If syntax is not an issue, I can imagine that some users might be put off by having to add an external object just to execute a command. There might be a perception that the Command property is faster to execute than EventToCommand for example.

 

Nikhil Kothari has an interesting alternative in his Silverlight FX framework where he can bind an event directly to a method on the VM. This avoids having to declare commands. Eventually I think that this is what we should have in the .NET framework. Having to resort to the third party ICommand implementation (either RelayCommand/DelegateCommand/etc… or custom built command classes) is annoying and should go away. I mentioned this to Anders Helsjberg when we were both in Belgium this spring, and he was apparently aware of the issue. I hope we see that coming soon (I know that Nikhil is pushing that within MSFT).

 

Cheers,

Laurent

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Brian Noyes


Sent: Tuesday, June 15, 2010 6:19 PM
To: wpf-di...@googlegroups.com

Bill Kempf

unread,
Jun 16, 2010, 9:30:12 AM6/16/10
to wpf-di...@googlegroups.com
I'm ALL for providing a mechanism to invoke a method on any object
from within XAML. I've been asking for this for years. However, I'd
point out that I've never used a command "just to invoke a method",
instead using my own solutions to this problem (which are cumbersome,
due to not having designer support). Also, despite having my own
solutions, I've never used them on events associated with the Command
property of a control. I've always used commands in those situations,
and will continue to always use them in the future no matter how nice
of a solution you come up with for invoking methods from XAML. Like I
said, I view these as two very different concepts, and there's a
reason to use both. I think that if you come up with a nice method
invocation story, but fail to make commands first class citizens in
SL, you'll have failed.

Brian Noyes

unread,
Jun 16, 2010, 9:33:04 AM6/16/10
to wpf-di...@googlegroups.com
No, again to be very clear. There is no consideration of removing commands. Just a discussion on whether to favor using Behaviors in the Prism samples and whether to make any guidance recommendations along those lines in the Prism docs.

On Wed, Jun 16, 2010 at 12:46 AM, Peter O'Hanlon <pete.o...@gmail.com> wrote:
Are you saying here that the long term vision is to move away from Commanding, or remove Commanding altogether? IMHO this second option would be a bad move and would alienate a lot of people who have invested a lot of time and money in their code only to effectively have it obsoleted for no real reason that I can see. As long as the tooling supports both, then let people use both - I, for one, prefer Commands for click behaviour because they are discrete and easy to code and test in isolation, whereas MEs have required that little bit more infrastructure for testing.
 
Part of the reason here is that people do seem to like POCO, but MEs can put people off because they require a deeper understanding of the subsystem (not true, I know, but it is a perception).

On 16 June 2010 01:31, Glenn Block <glenn...@gmail.com> wrote:
On the platform side there have been lots of disciussions on moving
away from it long term. One of the reasons we were pushing for markup
extensions in SL was to support a custom ME for calling methods.

On 6/15/10, Brian Noyes <brian...@softinsight.com> wrote:
--
Sent from my mobile device



--
Peter O'Hanlon

Bill Kempf

unread,
Jun 16, 2010, 9:33:47 AM6/16/10
to wpf-di...@googlegroups.com
I'm not sure we agree about what fits in Category 1. Like I said in my
last e-mail, I would be very unlikely to ever use a CallMethodAction
on any event associated with a control's Command property.

Glenn Block

unread,
Jun 16, 2010, 9:35:52 AM6/16/10
to wpf-di...@googlegroups.com
Do you agree that today often folks use commands for Category 1 ie
usages of DelegateCommand?

Glenn Block

unread,
Jun 16, 2010, 9:36:43 AM6/16/10
to wpf-di...@googlegroups.com
I am not saying you would, what I am really saying is these are two
types of concerns which don't necessarily need the same solution.

Bill Kempf