Commands vs Behaviors in MVVM

[Brian Noyes]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Yeah, that was my point (which I could have made more clearly, sorry).

[Brian Noyes]

Gotcha.

[Bill Kempf]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Lol

[Peter O'Hanlon]

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]

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]

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]

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]

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.

Old thoughts on teasing apart the concepts in Commands here http://blogs.msdn.com/b/johngossman/archive/2008/11/01/some-thoughts-on-the-routedcommand-design.aspx

[Daniel Vaughan]

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]

Yeah, we need VS to support behaviors.  Karl, I assume this is on the list for next time?

[Laurent Bugnion]

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]

No worries. Whatever you guys work up, remember less xaml is sometimes more ;-)

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

[Laurent Bugnion]

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]

Agreed, could not agree more

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

[Peter O'Hanlon]

Oh yes. That would be good.

--
Peter O'Hanlon

[Laurent Bugnion]

Totally agreed.

> > *To:* wpf-disciples@googlegroups..com

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

[Glenn Block]

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]

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]

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]

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]

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]

These are good points and issues that will have to at least be
addressed to go down that route.

[Peter O'Hanlon]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Do you agree that today often folks use commands for Category 1 ie
usages of DelegateCommand?

[Glenn Block]

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]

OK, let me try and address this narrower view. Let's say I have a
button on my form that should do some work when clicked. Doesn't
matter what that work is for this discussion. With a CallMethodAction
or other concept and a command, I'd have two very different choices on
how to invoke the work that needs to be run when clicking the button.
Presumably, CallMethodAction will be the easier of the two to just
wire up a method on ViewModel to perform the operation. So, which do
you think I'll use? That's right, I'd use a command.

Why?

The command is reusable. Even if currently the button is the only way
a user can invoke the operation, tomorrow the design might change and
we'll add a context menu, a keybinding, a mouse gesture and a double
click operation on a list. CallMethodAction isn't going to enable this
sort of reuse, when you take into consideration the execute/query
duality of a command.

There's plenty of need for a CallMethodAction, but I don't believe I'd
ever recommend using it instead of a command for any event associated

with the Command property of a control.

--

[Bill Kempf]

People do all sorts of crazy things. I don't use commands today for
anything I'd consider to fit into category 1, and that's all I can
speak to. However, I have to stress that I consider most scenarios
involving the event associated with a controls Command property to not
fit in category 1. The need to reuse the execute/query concept in
these situations is far to common.

[Glenn Block]

What do you use for category 1 type scenarios?

[Glenn Block]

OK, but how much of that is a choice that you are making based on
particular benefits vs something the general masses would/should do?

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

[Bill Kempf]

When should you ever recommend, for the masses or otherwise, not
coding with reuse in mind? :)

I'm not dogmatic. If you use a CallMethodAction for a button click,
I'm not going to tell you that you're doing it wrong. However, any
guidance that suggested, or even just hinted, that CallMethodAction is
preferred in this scenario I'd have to strongly disagree with. From an
architectural point of view, this advice is wrong, IMHO.

[Glenn Block]

Look personally I am big fan of reuse / seperation ie why I workred on MEF :-)

[Glenn Block]

Nikhil has a pretty interesting intermidiary approach. He introduces a
XAML friendly command which invokes a method on a model and which you
put in local resources. This way the VM doesn't have to expose a
command, and you get the resuse. You also get separation of concerns
in that the UI binds to the command rather than knowing the model /
method. He illustrated it in hos MIX MVVM talk.

[CBl...@eki-consulting.com]

This is similar to some of the Twitter discussions I have been having with Nikhil and Jeff Handley about the public EntityCollectionView which is being planned for the next version of WCF RIA Services. Nikhil doesn't like ICollectionView/IEditableCollectionView and feels that he wants the view to add or remove entities from the collection that he would call methods on the ViewModel to do that instead of flowing that back to the ViewModel through the IEditableCollectionView interface.

Personally, I don't like the idea of the View having to guess if the contents of the collection is editable or not through some other method and metadata, which is really only useful to tooling like Blend, isn't a valid substitute to me. I like my ViewModel to be discoverable at the code level, not just at the Blend level.

I have been thinking that the EntityCollectionView is something that should be discussed here at some point since it will eventually impact both Silverlight and WPF. The design I have been pushing on Jeff is something similar to a standard ICollectionView but instead of using Filter, SortDescriptions, and GroupDescriptions it would be LINQ based. In particular, it should support EntityQuery as well as standard queries so that the same LINQ query can be used for both loading data and filtering/sorting the EntityCollectionView. Adding. Removing. and Paging abilities would be provided by callbacks passed into the ECV through the constructor.

I think the design philosophy of the ECV is very similar to the design philosophy of the ICommand so I can see where Bill is coming from.

Bill Kempf <wek...@gmail.com> Sent by: wpf-di...@googlegroups.com 06/16/2010 10:05 AM AST Please respond to wpf-di...@googlegroups.com	To	wpf-di...@googlegroups.com
	cc
	bcc
	Subject

Re: [WPF Disciples] Commands vs Behaviors in MVVM

When should you ever recommend, for the masses or otherwise, not
coding with reuse in mind? :)

I'm not dogmatic. If you use a CallMethodAction for a button click,
I'm not going to tell you that you're doing it wrong. However, any
guidance that suggested, or even just hinted, that CallMethodAction is
preferred in this scenario I'd have to strongly disagree with. From an
architectural point of view, this advice is wrong, IMHO.

On Wed, Jun 16, 2010 at 9:57 AM, Glenn Block <glenn...@gmail.com> wrote:
> OK, but how much of that is a choice that you are making based on
> particular benefits vs something the general masses would/should do?
>

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

>>> On Wed, Jun 16, 2010 at 12:46 AM, Peter O'Hanlon <pete.o...@gmail.com>

[Bill Kempf]

I don't "expose a command" from my ViewModel. I use standard
RoutedCommands and CommandBindings.

public MyViewModel(ICommandTarget commandTarget)
{
commandTarget.CommandBindings.Add(new
CommandBinding(MyCommands.Foo, FooExecuted));
}

Onyx supplies me with the ICommandTarget service associated with the
View, and I add bindings to it in the ViewModel's constructor.

[Glenn Block]

Not in SL you don't.

[Glenn Block]

I remember we ran into a bunch of isses in Prism V1 related to routed
commands which is why we did not promote them. In particular there
issues related to composite UIs where the element bound to a command
was not in the visual tree or something. I am sure Brian remembers.

[Bill Kempf]

You're right that I don't today. However, this is something I've meant
to make work, and I have some ideas on how to go about it. However, I
did say that SL needed to be brought up to speed here. Commands should
be first class citizens in SL, regardless of any other discussions.

[Brian Noyes]

It was a combination of three factors:
- coupling with the visual tree
- complicated interaction with the focused element
- No way to have multiple handlers for the same command (i.e. Submit All
button with several open Order views where the Submit logic resides in the
ViewModel for each individual order)

It looks like Bills approach addresses some of those by using a proxy that
goes into the command binding that can still dispatch to a ViewModel and
get the handling out of the view, which addresses the first issue. Not
clear to me whether it handles the SubmitAll scenario.

I talk about the complexities of the focus stuff in my MSDN Magazine
article on Routed events and commands some, and more so in this follow on
post:
http://briannoyes.net/2008/11/09/TheTruthAboutRoutedCommandsRouting.aspx

Because of all these, we went with the DelegateCommand and
CompositeCommand approach and got the command handling out of the visual
tree and into our code's hands as quickly as possible. There are
definitely still scenarios where RoutedCommands still make sense,
Cut/Copy/Paste being the poster child. Things that are inherently coupled
to the view and the focus are fine to implement as custom RoutedCommands
for example. But otherwise I have shied away from them.

[Sacha Barber]

Agree with Bill I do

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

[Bill Kempf]

I believe the service approach does take care of the "coupling with
the visual tree" issue. The "complicated interaction with the focused
element" I see as a feature and not an issue, for the most part. I
know I'm in the minority on that point of view, but I've not had
issues here, so I'll stick to my opinion noting I reserve the right to
change it in the future ;). For the final one, I simply wouldn't do
that. Instead, I'd have one handler coupled with an event aggregator
or other such implementation.

Basically, my solution is the same solution provided by WPF. It has
the same benefits and the same drawbacks. I will note, however, that
one people were complaining about how the first implementations of the
RibbonCommand wasn't "MVVM Friendly", using my approach I had no
issues with the design. ;)

[Daniel Vaughan]

Shortcut registration is also an important part of using commands.
I also use an a ICommand registration service approach in Calcium
(ICommandService). A benefit of using this approach is that one is
able to register ICommands with a top level container. It also offers
the opportunity to manage shortcut registrations for all commands.
Yet, contending with focus issues hasn’t been easy as Brian states. In
a complex UI there is a lot of logic for determining when a view is in
fact active. Case in point, look at VS and the manner in which some
‘commands’ are enabled using a fallback mechanism. If a command is
intended for say the text editor, and there is no document present,
then the command will fall back to the active tool. This kind of
behaviour is something I have been refining in Calcium, and it isn’t
made easy by the manner in which focus works. My belief is that the
routed command system provided in WPF is inadequate to support these
scenarios easily. It’s nice for forms, but doesn’t cut it for multiple
disparate visual subtrees.

> On 6/16/10, Bill Kempf <weke...@gmail.com> wrote:
> > I don't "expose a command" from my ViewModel. I use standard
> > RoutedCommands and CommandBindings.
>
> > public MyViewModel(ICommandTarget commandTarget) {
> >    commandTarget.CommandBindings.Add(new
> > CommandBinding(MyCommands.Foo, FooExecuted)); }
>
> > Onyx supplies me with the ICommandTarget service associated with the
> > View, and I add bindings to it in the ViewModel's constructor.
>

> > On Wed, Jun 16, 2010 at 12:36 PM, Glenn Block <glenn.bl...@gmail.com>

> wrote:
> >> Nikhil has a pretty interesting intermidiary approach. He introduces
> >> a XAML friendly command which invokes a method on a model and which
> >> you put in local resources.  This way the VM doesn't have to expose a
> >> command, and you get the resuse. You also get separation of concerns
> >> in that the UI binds to the command rather than knowing the model /
> >> method. He illustrated it in hos MIX MVVM talk.
>
> >> Glenn
>

> >> On 6/16/10, Bill Kempf <weke...@gmail.com> wrote:
> >>> People do all sorts of crazy things. I don't use commands today for
> >>> anything I'd consider to fit into category 1, and that's all I can
> >>> speak to. However, I have to stress that I consider most scenarios
> >>> involving the event associated with a controls Command property to
> >>> not fit in category 1. The need to reuse the execute/query concept
> >>> in these situations is far to common.
>

> >>> On Wed, Jun 16, 2010 at 9:35 AM, Glenn Block <glenn.bl...@gmail.com>

> >>> wrote:
> >>>> Do you agree that today often folks use commands for Category 1 ie
> >>>> usages of DelegateCommand?
>

> >>>> On 6/16/10, Bill Kempf <weke...@gmail.com> wrote:
> >>>>> 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.
>
> >>>>> On Wed, Jun 16, 2010 at 9:20 AM, Glenn Block

> >>>>> <glenn.bl...@gmail.com>

> >>>>> wrote:
> >>>>>> 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
>

> >>>>>> On 6/16/10, Bill Kempf <weke...@gmail.com> wrote:
> >>>>>>> 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.
>
> >>>>>>> On Wed, Jun 16, 2010 at 9:05 AM, Glenn Block

> >>>>>>> <glenn.bl...@gmail.com>

> >>>>>>> wrote:
> >>>>>>>> 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?
>

> >>>>>>>> On 6/16/10, Bill Kempf <weke...@gmail.com> wrote:
> >>>>>>>>> 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

> >>>>>>>>> <laur...@galasoft.ch>

> >>>>>>>>>> <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
>

> ...
>
> read more »

[John Gossman]

You are the only person I've ever talked with who likes WPF's commands. 

[John Gossman]

See my blog post on how RoutedCommands conflate concepts.

[Bill Kempf]

The implication being that I must be wrong?

[John Gossman]

Didn't mean to imply that (I'm on vacation and using a poor internet connection...just being succinct).  No need to be sensitive...it's not a question of computer science purity, it's a practical question of what the mass of developers who use our stuff are telling us.  Some of our customers love F#, which is clearly a work of brilliant computer science, but most people don't get it.

  Clearly a lot of us spent a lot of time and brain power on WPF Commands, but most of the feedback we've gotten is negative.  Somehow, the way you design your apps or the problems you are solving match the way RoutedCommands work...but for most people they are confusing and don't do what they want.

 

The only thing I was trying to imply is that unless you convince a bunch of other folks to share your views, we will not be adding the RoutedCommands from WPF to Silverlight.  We will try to solve the scenarios. Calling methods from XAML (which I fought against for years) is only one part of the solution.  I believe that the design I outlined in my blog, with Verbs and AbstractGestures and generalization of Bindings covers all the same territory but (I hope) is clearer and allows new folks to pick and choose want they want to learn and use better.  Frankly, we may not even do that much.  Most customers are just telling us they either don't see the scenarios or solve them some other way, and with SL's minimalist philosophy we'll probably spend the resources better integrating Behaviors and other technologies that people tell us they want.

 

How's that for a vacation post?

[Sacha Barber]

Yes nice post, now enjoy some holiday time man

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

[Laurent Bugnion]

Sounds like someone is missing work… ;)

[Bill Kempf]

I wasn't being sensitive. It was an honest question. I didn't
understand the point of saying that I was the only person you'd heard
that liked WPF's commands. After all, that's anecdotal evidence at
best. I can tell you that I know a lot of people who share my view
point about commands. Seems like a couple on this list at least agreed
in part. My own anecdotal experience has actually been the opposite of
yours... other than a few developers, mostly within Microsoft, the
ones I speak with like commands.

RoutedCommands may be something different. I've never run into the
issues that I know exist with them, so it's hard to convince me to be
anti-RoutedCommand. However, given problems do exist, I'm not
campaigning to have them added to SL.

As for the rest... well, all I can say is that it makes me glad I'm a
WPF developer and not a Silverlight developer. Sorry, but I honestly
think you're making the wrong decisions.

[Peter O'Hanlon]

I'm with Bill on being a Command lover. I've invested a lot of time and effort in them, and have found them to be useful - so much so that I use an adaptation of Laurent's EventToCommand to hook things like listview selection to default commands (for instance).

--
Peter O'Hanlon

[Sacha Barber]

+1 for Commands, in fact in CinchV2 I have something called a ReverseCommand that allows the View to call the view. These commands can be used as TargettedTriggers for Actions, and it works great, no code behind, no mediator all in XAML.

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

[Sacha Barber]

Sorry meant ViewModel calling View

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

[CBl...@eki-consulting.com]

As an experiment yesterday, I showed the other SL programmers where I work the CallMethodAction behavior. None of us use Blend very much so nobody had really looked at it before. Everyone had the same reaction: CallMethodAction doesn't "smell" right to them and they would much rather continue to use commands.

One question I was asked, if the P&P team is worried about best practices and what is the best way of doing things, why are they considering using an inferior way of doing things just because it is easier to explain to somebody. The point about multiple concepts and patterns also wasn't understood, the Command pattern feels like any other binding to us, it is the behavior that seems like a different way of doing things.

Brian Noyes <brian...@softinsight.com> Sent by: wpf-di...@googlegroups.com 06/15/2010 09:19 AM MST

Please respond to wpf-di...@googlegroups.com

To

wpf-di...@googlegroups.com

cc
bcc

Subject

[WPF Disciples] Commands vs Behaviors in MVVM

[Peter O'Hanlon]

Good point. Should lesser practice be enthused about because they are more convenient?

--
Peter O'Hanlon

[Brian Noyes]

Well, that is the problem. "Inferior" is in the eyes of the beholder. Not surprisingly, I posted the same query on the Silverlight insiders list. The response there, although less heated, has been strongly in favor of behaviors. Not surprising since until SL4 that was there only option and until VS 2010, they pretty much had to use Blend to be effective with SL UI design.

But I've been fighting this battle on the team because they were in the camp that behaviors are superior because they can cover more scenarios and you don't have to mix two different constructs to cover all your scenarios. So consistency was winning out.

Thanks to all the comments on the list here, I think I am swaying them back the other way. At a minimum, I don't think we will make any recommendations of commands over behaviors, and as I mentioned before, there was never any intention of removing DelegateCommand and CompositeCommand from the Prism libraries or the existing QuickStarts and RI that use them. 

The only remaining question is whether I can convince them to use commands in the new QuickStarts and RI we are building.

I think the discussion here has also helped to give the product teams some meat to chew on for future support of commands in the framework.

Brian

--

[Sacha Barber]

Glad to be of service

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

[John Gossman]

well, i'm obviously not being clear over email (since I was referring to your example using RoutedCommands), so I'll just apologize and leave it.

[Sacha Barber]

I dont know how many folk here actually use RoutedCommands, I think most use some sort of delegateCommand right?

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

[Peter O'Hanlon]

That's what we're here for - to be awkward buggers.

--
Peter O'Hanlon

[Peter O'Hanlon]

+1 for delegate command variant.

--
Peter O'Hanlon

[Sacha Barber]

you are

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

[Peter O'Hanlon]

No - I'm a curmudgeonly, grumpy old sod.

--
Peter O'Hanlon

[Laurent Bugnion]

John was just talking about RoutedCommands, not commands in general. Commands are in Silverlight because he fought for them in the first place.

 

I am not a fan of RoutedCommands myself. While they can be great to use for an experienced developers, I saw them make WPF beginners (for some developers with years of experience in other technologies) totally confused. Great that they are there, but while I mentioned them the last time I taught WPF to a group of beginners, I didn’t go deep into them. I spent more time showing normal commands and of course RelayCommand.

 

Cheers,

Laurent

[Bill Kempf]

My example used RoutedCommands, because that's what's available in WPF
by default. I'm not concerned by the implementation details, which is
where the issues come in with RoutedCommands. Provide me with a
different sort of Command, I'll use it.

I prefer RoutedCommand over Delegate/RelayCommand not because it's
Routed, but because of CommandBindings. That, and the fact that the
built-in set of commands are RoutedCommands.

[Bill Kempf]

Oh, and I know I'm in the minority in not preferring Delegate/RelayCommand.

[Sacha Barber]

Yaeh you is strange wierd one, how did you get on this list. You don't like delegateCommand, who are you, you suck man.

ha Ha only joking of course Bill, I find I just get all I want from DelegateCommands is all

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

[Bill Kempf]

Didn't say I don't like DelegateCommand. That would be a strange thing
to say, since I independently discovered the concept at the same time
as so many of the rest of us. In fact, that's how I "met" Mr. Brown
online... I commented on his blog post about the concept laughing at
how we'd both independently come up with the same idea. :)

That said, yes, "I is strange one wierd one", and I have no idea how I
got on the list ;).

[Sacha Barber]

I know how you did.

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

[Paul Stovell]

Hi Brian,

Just on this, one issue I encountered is versioning. I found Blend 4 didn't work very nicely with my custom behaviors that used Blend 3's Sys.Win.Interactivity.dll. It showed the behaviors in the Objects and Timelines view, but it didn't show me any properties, and wouldn't allow me to edit them, until I upgraded. 

If Prism had an Interactivity.dll dependency, every time a Blend RC is released, you'll need to release a new Prism build (unless they come up with a better versioning solution going forward, or merge it into the framework). I'm struggling with this same issue with Magellan. I'd like to know if anyone else found a good workaround to make 3.0 behaviors just work under Blend 4.0.

Paul

On Wed, Jun 16, 2010 at 6:44 AM, Brian Noyes <brian...@softinsight.com> wrote:

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-di...@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
Subject: [WPF Disciples] Commands vs Behaviors in MVVM

 

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
-----------------------------------------

 

--
Paul Stovell