Question

我一直在使用MVVM Light一段时间 - 它非常有用，几乎总是我添加到新项目中的第一个库！

我想知道开发一个实现INotifyPropertyChanged来封装可绑定属性的类会产生什么影响（例如下面的例子）。

public class BindableProperty<T> : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;


    private T mValue;
    public T Value
    {
        get { return mValue; }
        set
        {
            if (!EqualityComparer<T>.Default.Equals(mValue, value))
            {
                mValue = value;
                if (PropertyChanged != null)
                {
                    PropertyChanged(this, new PropertyChangedEventArgs("Value"));
                }
            }
        }
    }


    public BindableProperty(T default_value)
    {
        mValue = default_value;
    }
}

使用这个类，我必须更改我的Xaml，但我相信我的ViewModel可能更具可读性（下图） - 特别是当属性数量增加时。

<TextBox Text="{Binding FirstName.Value, UpdateSourceTrigger=PropertyChanged}"/>

public class MainVM
{
    public BindableProperty<string> FirstName { get; private set; }
    public BindableProperty<string> LastName { get; private set; }

    public MainVM()
    {
        FirstName = new BindableProperty<string>("");
        LastName = new BindableProperty<string>("");
    }
}

我知道MVVM Light的设计非常灵活，轻巧，并提供完全控制（它做得非常好）。我当然可以组合实现并使用上面的BindableProperty类来获取一些属性，并在更复杂的情况下使用更明确的ViewModelBase代码来获取其他属性。

我错过了一些明显的东西吗？我可能没有注意到这种设计的一些权衡（例如，更改xaml绑定的含义，数据验证......）？

Answer 1

封装属性没有额外的价值。这可能适用于非常简单的场景，但只要ViewModel变得更加复杂，您就会以奇怪的方式连接封装的类。

如果您拥有相互依赖的属性，即array，FirstName和LastName {{1}，这种方法在验证方面也不会很好。 }只是一个FullName。

同样适用于验证（使用FullName）。使用基类，您的代码看起来像

public string FullName { get { return FirstName+" "+LastName; } }

在封装属性中实现这将是一件痛苦的事情

MVVM Light ViewModelBase vs Encapsulation

1 个答案: