8

我已经阅读了将模型数据的更改传达给视图模型的各种方法。有人建议模型应该尽可能实现 INotifyPropertyChanged，以便它可以通知视图模型更改的属性。有人建议在模型和视图模型之间建立一个服务层，服务层实现 INPC，方法调用通过该服务层路由到模型，以便服务层通知视图模型。

我认为后者是前者的更精细的修订版，并且已经开始在我的模型类中实现 INPC。感觉不对，因为

a) 我现在必须在我的视图模型中为来自模型的通知编写一个事件处理程序。这采用长开关（propertyName）的形式，它在视图模型上设置相应的属性，导致 NPC 再次向上发送。我觉得我在这里写了很多样板代码。

b) 视图模型现在通过一堆字符串耦合到我的模型，这些字符串完全由约定规范，即没有定义“接口”。更不用说这会导致 IDE 的困难。

c）我的模型必须修改以适应这种情况！如果由于某种原因关闭了怎么办？我认为这样的模式旨在提高代码的可重用性和关注点的分离。不仅如此，触发 INPC 事件所需的代码也是乏味和重复的，而且不是真正抽象的。

我真的很想知道 WPF 专业人员如何通过依赖属性等来解决这个问题。我觉得我错过了一些东西。我不热衷于使用想要“从头开始”学习的框架。我已经离开 WPF 一两年了，最近使用 AngularJS 让我质疑我的方法。

谢谢！

4

1 回答 1

7

出于此答案的目的，我将业务对象类称为“数据类型”。

以我个人的经验，视图模型总是与数据类型相关联。您必须具有要显示的类型的属性，因此始终存在从视图模型命名空间到数据类型命名空间的引用。

您所说的模型（根据您在评论中的描述）听起来像我的视图模型。我的视图模型具有属性，主要是各种数据类型类和方法的类型，而我的数据类型类大部分只包含属性……它们只是数据的持有者和变化的报告者。

您似乎认为该INotifyPropertyChanged接口在您调用它的“模型”和视图模型类之间执行一些职责......在我看来，这充其量是可选的......来自MSDN的INotifyPropertyChanged 接口页面：

INotifyPropertyChanged 接口用于通知客户端（通常是绑定客户端）属性值已更改。

因此，我将界面视为视图与视图模型和数据对象INotifyPropertyChanged之间的“生命线” 。一些开发人员更喜欢将每种数据类型“包装”在自己的视图模型中，但我更喜欢直接在我的数据类型中实现接口。INotifyPropertyChanged

我这样做的主要原因是我可以在我拥有的自定义集合类中连接到这个框架。这使我能够拥有知道对集合中任何项目中的任何属性所做的任何更改的集合。它还使我能够将数据同步构建到我的基类中，以便对象知道它们何时有任何更改。

它还节省了为每个数据类型类创建匹配视图模型类的时间。为什么有两个班可以做一个可以做的事？我从来不需要那种程度的分离。如果我对您的理解正确，那么在您的数据类型类中实现此接口将不需要执行您的观点 a)。

如果您可以使用 .NET 4.5 ，您的某些点 b) 和 c)也可能会无效，因为您可以使用一个新CallerMemberNameAttribute属性自动将每个属性的名称提供给PropertyChanged处理程序。我找到了一篇名为C# 5–Making INotifyPropertyChanged Easier的好文章，其中有很好的描述。

我现在已经编写了几个大型 WPF 应用程序和一些框架，并且INotifyPropertyChanged在我的数据类型类中实现接口从来没有遇到过问题。事实上，如果我必须为每个数据类型类实现包装视图模型类，我认为我不可能同时编写它们。到目前为止，这种方法对我很有帮助，我打算坚持下去，直到至少找到更好的方法。然而，这只是一位开发人员的意见，您必须选择适合您的方式。

于 2013-08-28T22:18:28.543 回答