这两种变体(性能,内存泄漏或指南)之间是否存在差异?
NPC:
private ICommand mGoBackCommand;
public ICommand GoBackCommand
{
get { return mGoBackCommand; }
set
{
if (mGoBackCommand != value)
{
mGoBackCommand = value;
RaisePropertyChanged("GoBackCommand");
}
}
}
自动属性:
public ICommand GoBackCommand {get; set;}
UPD: 最后的问题是: 我是否可以在VievModel中使用自动属性,如果它们是在构造函数中分配一次的简单命令,或者由于性能,内存泄漏或其他原因我需要在VM的每个属性上实现NPC?
答案 0 :(得分:6)
如果您正在编写一个实现INotifyPropertyChanged
的类,那么您正在签订一份合同,说明“当任何属性发生更改时,我会引发PropertyChanged
事件。”
但是,如果您知道某个属性在实例的生命周期内不会发生变化,那么您通过永远不会为该属性提升PropertyChanged
来满足该合同。
所以,如果你在构造函数中设置一次属性(“将它设置为忘记它”属性),那么你不需要破坏属性只是为了支持INotifyPropertyChanged
而你可以使用自动 - 实施的财产。但是,您应该在此处更改属性:
public ICommand GoBackCommand { get; set; }
到此:
public ICommand GoBackCommand { get; private set; }
这样就不会在课堂外意外修改。
答案 1 :(得分:3)
对于在构造期间分配Command的场景,不需要引发PropertyChanged事件。但是,有些情况下您可能希望根据视图模型状态的更改来更改命令(例如,许多媒体播放器只有一个按钮用于播放和暂停,当媒体播放时您想要更改命令支持它暂停,当它暂停时你想改变它来玩)。在这些情况下,您应该将PropertyChanged事件用于您的命令...或者您可以保留相同的命令,并让它根据状态处理要执行操作的逻辑。
希望这有帮助。
答案 2 :(得分:1)
如果有任何内容绑定到GoBackCommand
,则只有通过INPC或DependencyProperty
实现更改通知时,对它的更改才会传播到绑定目标。否则,绑定目标将不知道该属性已更改,并将保留它在第一次绑定时拉出的值。
答案 3 :(得分:0)
我从未见过人们使用NPC命令。正如你所提到的那样,你只是在ctor上初始化它,NPC附加它有什么意义?
您是否在运行时更改了命令?如果没有,就没有必要了。
你可以使用绑定:
<Button Content="Go Back" Margin="30,10" Command="{Binding GoBackCommand}"/>