3

我有一个实现INotifyPropertyChanged的​​类，也有自己的属性概念，有点像这样：

class sealed MyClass : INotifyPropertyChanged
{
    private Dictionary<string, object> _properties;

    public object GetProperty(string name)
    {
        return _properties[name];
    }

    public object SomeProperty
    {
        get
        {
            return GetProperty("SomeProperty");
        }
    }
}

请注意，一些常见的属性也有 C# 访问器。

我想引发一个事件来通知其他人某个属性（通过 GetProperty 方法访问其值）已更改，即使此属性没有相应的 C# 访问器也是如此。

假设没有发生冲突的风险（即无意中为值未更改的 C# 属性引发属性更改事件 - 请注意此类是密封的），是否有任何理由我不能只使用该INotifyPropertyChanged.PropertyChanged事件来通知其他人，还是我应该为此添加自己的事件？

4

3 回答 3

2

我建议你添加自己的。尽管没有特定原因会导致代码中断，INotifyPropertyChanged但具有特定的预期用途，并且许多潜在消费者都可以理解。我不会亲自编写与之相矛盾的代码，以防万一。

于 2012-08-15T14:06:17.647 回答
0

据我所知，PropertyChanged为不存在的房产筹集资金并没有什么坏处，但我认为这也不是很有用。INotifyPropertyChanged主要由数据绑定系统（在 WinForms、WPF、Silverlight ...）中使用，这些系统不知道如何访问您的自定义“属性”。

现在，您可以做的是实现ICustomTypeDescriptor以标准方式提供对自定义属性的访问。这适用于 Windows 窗体和 WPF，我不确定其他框架。

当然，如果您不打算将其用于数据绑定，您仍然可以使用此事件来通知您的类的消费者值已更改。

于 2012-08-15T14:11:08.987 回答
0

从技术上讲，这取决于订阅者PropertyChanged以及他们对PropertyChanged事件的响应。如果他们不尝试读取 .NET “属性”，那没关系。

但是，这确实引入了耦合，而 INPC 的使用正试图解耦。一般情况下的 INPC 假定PropertyChanged意味着 .NET 属性（具有给定名称）已更改，并且预计所有使用 INPC 的地方都会出现这种情况。即，您实施 INPC 是因为您想在任何接受 INPC 的地方使用您的对象。如果您的对象不能这样做，那么它就违反了 INPC 的默示合同。如果您有一个PropertyChanged处理程序执行的操作与读取属性不同，并且您只是因为 INPC 存在而重用它，那么编写您自己的接口可能是一个好主意。

于 2012-08-15T14:38:47.407 回答