我已经阅读了将模型数据中的更改传达给视图模型的各种方法。 有人建议模型应尽可能实现INotifyPropertyChanged，以便它可以通知视图模型已更改的属性。一些建议在模型和视图模型之间建立服务层，服务层实现INPC，方法调用通过此服务层路由到模型，以便服务层通知视图模型。
我认为后者是对前者的更细粒度的修订，并且已经开始在我的模型类中实现INPC。感觉不对，因为
a）我现在必须在视图模型中编写一个事件处理程序，用于模型中的通知。 这采用长开关（propertyName）的形式，它在视图模型上设置相应的属性，导致NPC再次向上发送。我觉得我在这里写了很多锅炉板代码。
b）视图模型现在通过一串字符串耦合到我的模型，这些字符串仅由惯例规定，即没有定义“接口”。更不用说这会导致IDE的困难。c）我的模型必须进行修改以适应这种情况！如果由于某种原因被关闭怎么办？我认为这样的模式旨在提高代码的可重用性和安全性。关注的问题。不仅如此，而且触发INPC事件所需的代码是繁琐且重复的，并且不是真正可抽象的。
我真的很想知道WPF专业人员如何通过依赖属性等来解决这个问题。我感觉我错过了一些东西。我并不热衷于使用一个框架，因为我想从头开始学习。 我已经离开WPF一两年了，最近和AngularJS一起工作让我质疑我的方法。
谢谢！
答案 0 :(得分：6)
出于本答案的目的，我将调用业务对象类的“数据类型”。
根据我的个人经验，视图模型始终与数据类型相关联。您必须具有要显示的类型的属性，因此始终会存在从视图模型命名空间到数据类型命名空间的引用。
你称之为模型（根据评论中的描述）听起来像我的视图模型。我的视图模型具有属性，主要是各种数据类型类和方法的类型，而我的数据类型类只占用了大部分属性......它们只是数据的持有者和变更的记者。
你似乎认为INotifyPropertyChanged界面在你称之为'模型'和视图模型类之间执行某些职责......在我看来，这是最好的选择......来自MSDN的INotifyPropertyChanged Interface页：
INotifyPropertyChanged接口用于通知客户端（通常是绑定客户端）属性值已更改。
因此，我认为INotifyPropertyChanged界面是视图与视图模型和数据对象之间的“生命之血”。一些开发人员更喜欢在自己的视图模型中“包装”每种数据类型，但我更喜欢直接在我的数据类型中实现INotifyPropertyChanged接口。
我这样做的主要原因是我可以在我拥有的自定义集合类中挂钩这个框架。这使我能够拥有知道对集合中任何项目中的任何属性所做的任何更改的集合。它还使我能够在我的基类中构建数据同步，以便对象知道它们何时有任何更改。
它还节省了为每个数据类型类创建匹配视图模型类的时间。为什么有两个班级可以做什么？我从来不需要那种程度的分离。如果我理解正确，在数据类型类中实现此接口将无需执行您的观点a）。
如果您可以使用.NET 4.5，则某些要点b）和c）可能也会无效，因为有一个新的CallerMemberNameAttribute属性可用于自动提供PropertyChanged处理程序的每个属性的名称。我发现了一篇名为C# 5–Making INotifyPropertyChanged Easier的好文章，其中有很好的描述。
我现在已经编写了几个大型WPF应用程序和一些框架，我在数据类型类中实现INotifyPropertyChanged接口时从未遇到过问题。事实上，如果我必须为每个数据类型类实现包装器视图模型类，我认为我不能在同一时间编写它们。到目前为止，这种方法对我很有用，我打算坚持下去，直到我找到一个更好的方法。然而，这只是一个开发人员的意见，你必须选择适合自己的东西。