14

I have a co-worker that asked me why he has to use the ICommand pattern.

He wants to add a button and then make an event for it in the code behind. Then from the event he wants to call a method on the ViewModel.

I gave him the obvious answer: This adds coupling between the View and the ViewModel. But he argued that the View and the ViewModel are already coupled. (We set our view's DataContext to the ViewModel in the View's code behind: DataContext = new MyViewModel();

Yes, I told him that his way adds "more coupling", but it sounded a bit lame even to me.

So, I know that ICommand is the clean way, and I do it that way. But what else does ICommand buy you besides not using an already existing coupling?

H.B.
  • 166,899
  • 29
  • 327
  • 400
Vaccano
  • 78,325
  • 149
  • 468
  • 850
  • I asked the same question here: http://stackoverflow.com/questions/3345124/what-is-the-real-advantage-of-keeping-code-out-of-the-xaml-code-behind – Matt Greer Dec 22 '11 at 21:39

5 Answers5

10

  • It's not about decoupling, but how deep you can penetrate inside your ModelView hierarchy: not event pumping, but event routing, built-in in the framework.

  • It's about UI managent: Command has state (CanExecute), if assign the command to the control, if command's state becomes false, control becomes disabled. It gives you powerful UI state management way, avoiding a lot of spaghetti coding, for complicated UI especially.

Tigran
  • 61,654
  • 8
  • 86
  • 123
4

I have a co-worker that asked me why he has to use the ICommand pattern.

It seems implied this is a standard at your company (whether explicitly stated or unspoken). That should be answer enough to his question.

If all company code is supposed to use that pattern, it can cause co-developer confusion and frustration when someone else has to debug his code.

Also, in my opinion, using ICommand is faster to develop / mock up because you don't NEED to have the ICommand property on the context to run your program. It lets your UI designers (if you are lucky enough to have them) completely finish their tasks even if you are behind in your coding.

Malcolm O'Hare
  • 4,879
  • 3
  • 33
  • 53
3

ICommand can also give you a place for handling wether or not a specific button can be used right then. this would be handled through the canexecute method.

tam
  • 1,583
  • 2
  • 13
  • 25
3

You can bind the CanExecute method of the command to the properties of a control, also a Command encapsulates an action in a nice way. In my opinion / experience this approach makes a lot of sense because you have both the condition and the execute action in a single abstraction, which makes it easier to understand and test.

If in the future you find that this action is repeated you can abstract it easily in your own custom ICommand and use it in several places.

Sebastian Piu
  • 7,838
  • 1
  • 32
  • 50
1

One thing that I don't see in the previous answers is that using the ICommand promotes code reuse by allowing the same action to be used by different GUI components. For example, if I had a command that should result in the opening of a window and that command could be invoked in three or for different screens in the application, an ICommand implementation lets me define that logic in a single place. With the code-behind event handlers, I have to copy and paste redundant code, in violation of DRY (or else, I'd have to roll my own implementation by abstracting out to a class, at which point, I might as well use ICommand).

Erik Dietrich
  • 6,080
  • 6
  • 26
  • 37