在实现INotifyPropertyChanged的ViewModel属性Setter中触发计算是否为不良实践？

嘿，这个问题问到点子上了——这是MVVM开发里非常常见的权衡场景，我来帮你理清楚各个方案的优劣：

在Setter中触发计算是不是不良实践？ #

其实没有绝对的“坏”，得看具体场景：

• 如果计算逻辑超简单（就像你说的TotalCost = Price * Quantity），直接在Price和Quantity的Setter里触发更新完全没问题，代码简洁直观，维护起来也没负担。
• 但如果计算逻辑复杂、依赖多个属性，或者未来大概率要扩展新的依赖项（比如后续加个Discount属性），这种写法就会踩坑：比如你得修改N个Setter的代码；要是同时修改多个依赖属性，还可能导致TotalCost被重复计算多次，有点浪费性能。

更优的替代方案 #

1. 把计算逻辑封装成单独方法（最通用的优化） #

不用搞复杂的框架，先把计算逻辑抽成一个私有方法，然后在相关属性的Setter里调用它。这样后续不管怎么改计算规则，只需要改这一个方法就行，比直接把计算写在Setter里好维护太多：

private decimal _price;
public decimal Price
{
    get => _price;
    set
    {
        if (_price != value)
        {
            _price = value;
            OnPropertyChanged(nameof(Price));
            UpdateTotalCost(); // 调用统一计算方法
        }
    }
}

private int _quantity;
public int Quantity
{
    get => _quantity;
    set
    {
        if (_quantity != value)
        {
            _quantity = value;
            OnPropertyChanged(nameof(Quantity));
            UpdateTotalCost();
        }
    }
}

private decimal _totalCost;
public decimal TotalCost
{
    get => _totalCost;
    private set
    {
        if (_totalCost != value)
        {
            _totalCost = value;
            OnPropertyChanged(nameof(TotalCost));
        }
    }
}

// 所有计算逻辑都在这里，改起来超方便
private void UpdateTotalCost()
{
    TotalCost = Price * Quantity;
    // 以后加Discount？直接改这里：
    // TotalCost = Price * Quantity * (1 - Discount);
}

2. WPF专属：用依赖属性的变更回调 #

如果是WPF项目，你可以把Price和Quantity定义为依赖属性，利用它自带的PropertyChangedCallback来触发计算——这是WPF原生设计来处理属性依赖关系的方式，非常规范：

public static readonly DependencyProperty PriceProperty =
    DependencyProperty.Register(nameof(Price), typeof(decimal), typeof(YourViewModel),
        new PropertyMetadata(0m, OnDependentPropertyChanged));

public static readonly DependencyProperty QuantityProperty =
    DependencyProperty.Register(nameof(Quantity), typeof(int), typeof(YourViewModel),
        new PropertyMetadata(0, OnDependentPropertyChanged));

private static void OnDependentPropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
    var vm = (YourViewModel)d;
    vm.TotalCost = vm.Price * vm.Quantity;
}

public decimal Price
{
    get => (decimal)GetValue(PriceProperty);
    set => SetValue(PriceProperty, value);
}

// Quantity和TotalCost的定义类似，TotalCost可以是普通属性或依赖属性

3. 响应式编程方案（ReactiveUI） #

如果你的项目用了ReactiveUI，那可以彻底摆脱手动触发计算的麻烦——它能自动监听属性变化，当依赖项更新时自动重新计算TotalCost：

private readonly ObservableAsPropertyHelper<decimal> _totalCost;
public decimal TotalCost => _totalCost.Value;

public YourViewModel()
{
    // 监听Price和Quantity的变化
    var priceChanges = this.WhenAnyValue(x => x.Price);
    var quantityChanges = this.WhenAnyValue(x => x.Quantity);
    
    // 组合两个流，计算TotalCost并绑定到属性
    _totalCost = Observable.CombineLatest(priceChanges, quantityChanges, 
            (price, quantity) => price * quantity)
        .ToProperty(this, x => x.TotalCost);
}

// Price和Quantity的Setter只需要触发PropertyChanged就行，不用管计算
private decimal _price;
public decimal Price
{
    get => _price;
    set => this.RaiseAndSetIfChanged(ref _price, value);
}

private int _quantity;
public int Quantity
{
    get => _quantity;
    set => this.RaiseAndSetIfChanged(ref _quantity, value);
}

这种方式的好处是依赖关系一目了然，而且能自动避免重复计算——只有当依赖属性真的变化时才会重新计算，性能也更好。

关于你想到的两个方案的小点评 #

• 订阅自身PropertyChanged事件：确实不推荐，PropertyChanged本来是给外部（比如View）用的通知机制，ViewModel内部用它来触发逻辑，会让代码可读性变差，还容易搞出循环调用的意外（比如TotalCost变化又触发其他属性更新，导致反复计算）。
• 绑定控件LostFocus事件：这真的违背了MVVM的核心——View和ViewModel要解耦。View只负责展示和绑定命令/属性，直接调用ViewModel方法会让两者绑定得太死，测试和维护都麻烦。

总结一下：简单计算直接在Setter里触发完全OK；如果逻辑复杂或要扩展，优先考虑封装计算方法、WPF依赖属性回调，或者用响应式框架来处理。

内容的提问来源于stack exchange，提问作者Shane