It is necessary to use INotifyPropertyChanged on properties of type ICommand in WPF MVVM?

Question

Is there a difference between this two variants (performance, memory leaks or guidelines)?

With NPC:

private ICommand mGoBackCommand;

    public ICommand GoBackCommand
    {
        get { return mGoBackCommand; }
        set
        {
            if (mGoBackCommand != value)
            {
                mGoBackCommand = value;
                RaisePropertyChanged("GoBackCommand");
            }
        }
    }

Auto property:

public ICommand GoBackCommand {get; set;}

UPD: Final question is: Can I use auto properties in VievModel if they are simple commands which will be assigned once in constructor, or I need implement NPC on each property of the VM because of performance, memory leaks or something else?

Answer 1

If you are writing a class that implements INotifyPropertyChanged , you are making a contract that says "I'll raise the PropertyChanged event when any property changes."

But, if you know for a fact that a property won't change during the lifetime of the instance, then you trivially satisfy that contract by never raising PropertyChanged for that property.

So, if you set a property once in the constructor (a "set it a forget it" property), then you don't need to mangle the property just to support INotifyPropertyChanged and you can use an auto-implemented property. However, in this you should change the property from this:

public ICommand GoBackCommand { get; set; }

to this:

public ICommand GoBackCommand { get; private set; }

so that it cannot be accidentally modified outside the class.

Answer 2

For scenarios where the Command is assigned during construction, raising the PropertyChanged event is not necessary. However, there are cases where you may want to change the command based on a change in the state of your viewmodel (for example many media players have a single button for play and pause, when the media is playing you want to change the command backing it to pause, when it's paused you want to change it to play). In those cases you should use the PropertyChanged event for your command...or you can keep the same command and have it handle the logic on which action to perform based on state.

Hope this helps.

Answer 3

If anything is bound to GoBackCommand , changes to it will only propagate to the binding target if you implement change notification via INPC or via DependencyProperty 's. Otherwise, the binding target will have no idea that the property has changed and will retain the value it pulled when it first bound.

Answer 4

I have never seen people use NPC for commands. As you have mentioned that you only initializa it on ctor, what's the point of having NPC attached to it?

Are u changing your command in runtime? if not, there is no need.

you can use binding:

<Button Content="Go Back" Margin="30,10" Command="{Binding GoBackCommand}"/>