RoutedUICommands vs ICommand. When & Why
-
Hope the title is OK. Didn't know how to put it any better. I am looking here for some background information, opinions if you will. I know how to code them. But I can't get my head around why sometimes things are done one way and sometimes the other. If you read WPF books (mostly) they teach you to implement RoutedUICommands. So in short, to have a static class with commands, commandbindings in XAML and some codebehind. If you read some of the MVVM articles on this site or this article http://msdn.microsoft.com/en-us/magazine/dd419663.aspx[^]. They implement classes with ICommand interface and/or a RelayCommand : ICommand class and put some command handling in the ViewModel So, when and why, pros and cons, of using one or the other. This is what I hope to hear from you.
You should always write WPF code the MVVM way. It just produces cleaner, more organized and more efficient code. WPF and MVVM are really a match made in heaven. Once you get your MVVM framework situated, MVVM isn't all that difficult. People who don't want to take a couple of months to learn it and set up a framework are the only ones who make a big deal about how "hard and complicated" it is. If you try write a WPF the non MVVM way, you'll end up with a mess of spaghetti code.
-
You should always write WPF code the MVVM way. It just produces cleaner, more organized and more efficient code. WPF and MVVM are really a match made in heaven. Once you get your MVVM framework situated, MVVM isn't all that difficult. People who don't want to take a couple of months to learn it and set up a framework are the only ones who make a big deal about how "hard and complicated" it is. If you try write a WPF the non MVVM way, you'll end up with a mess of spaghetti code.
Very well, I agree that MVVM is a good pattern. But when not using RoutedUICommand class you loose the bubbling and tunneling, right? This wil not get me into problems?
-
Very well, I agree that MVVM is a good pattern. But when not using RoutedUICommand class you loose the bubbling and tunneling, right? This wil not get me into problems?
RelayCommand is really kind of required for MVVM. It allows you to define the CanExecute & Execute handlers as part of the RelayCommand object itself. With other types of command implementations, you need to add them to the CommandBindings collection which you don't really have access to in MVVM since the CommandBindingsCollection is part of the window and not the VM. You don't need bubbling and tunneling in VMs. Its mostly handling clicks and such.
-
RelayCommand is really kind of required for MVVM. It allows you to define the CanExecute & Execute handlers as part of the RelayCommand object itself. With other types of command implementations, you need to add them to the CommandBindings collection which you don't really have access to in MVVM since the CommandBindingsCollection is part of the window and not the VM. You don't need bubbling and tunneling in VMs. Its mostly handling clicks and such.
Hm, make good sense to me. Thx. :thumbsup:
-
Hm, make good sense to me. Thx. :thumbsup:
Oh, one other thing I can clear up for you... bubbling and tunneling is really only useful in controls IMO. You may have thought about using them to communicate between a child view and the parent, but that is really not the recommended pattern in MVVM. Most frameworks will include some sort of messenger service that basically lets you send async messages around to anybody who cares to listen for that specific message.
-
You should always write WPF code the MVVM way. It just produces cleaner, more organized and more efficient code. WPF and MVVM are really a match made in heaven. Once you get your MVVM framework situated, MVVM isn't all that difficult. People who don't want to take a couple of months to learn it and set up a framework are the only ones who make a big deal about how "hard and complicated" it is. If you try write a WPF the non MVVM way, you'll end up with a mess of spaghetti code.
SledgeHammer01 wrote:
If you try write WPF the non MVVM way, you'll end up with a mess of spaghetti code.
FTFY...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
SledgeHammer01 wrote:
If you try write WPF the non MVVM way, you'll end up with a mess of spaghetti code.
FTFY...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997Seriously? WPF seems way cleaner then MFC or Winforms. Sounds like you need a better MVVM framework :).
-
Seriously? WPF seems way cleaner then MFC or Winforms. Sounds like you need a better MVVM framework :).
better framework, like?
-
better framework, like?
The best framework is one you write yourself :) No joke. This is exactly what I did. There are a lot of popular frameworks out there: MVVM Light, Cinch, etc, but I've never been a fan of grabbing a bunch of open source libraries and getting them to work together. By writing it yourself, you learn MVVM and you know how stuff works inside. Imagine if you used Cinch and found some issue? Sascha is very active on CodeProject, but you never know what could happen down the road. Personally I like real light-weight stuff. So I pretty much have a full light-weight MVVM framework + light-weight DI container and don't have any of the Silverlight fluff that other libraries have.
-
The best framework is one you write yourself :) No joke. This is exactly what I did. There are a lot of popular frameworks out there: MVVM Light, Cinch, etc, but I've never been a fan of grabbing a bunch of open source libraries and getting them to work together. By writing it yourself, you learn MVVM and you know how stuff works inside. Imagine if you used Cinch and found some issue? Sascha is very active on CodeProject, but you never know what could happen down the road. Personally I like real light-weight stuff. So I pretty much have a full light-weight MVVM framework + light-weight DI container and don't have any of the Silverlight fluff that other libraries have.
I am not a fan of just grabbing a framework
either. At least you have to know the concept of what is happening in there. Otherwise when you will run into bug of the framework you will get stuck.
I am now in the process of making this decision. I know MVVM is the way to go. But I think I will start with my own implementation to see before I get involved in a framework.Do you know this framework?
Catel - Part 0 of n: Why choose Catel?[^]It’s a relative newcomer. What do you think of it?
