c# - 在 MVVM 中，ViewModel 或 Model 应该实现 INotifyPropertyChanged 吗？

Question

我处理过的大多数 MVVM 示例都有 Model 实现 INotifyPropertyChanged，但在 Josh Smith's CommandSink example 中ViewModel 实现了 INotifyPropertyChanged。

我仍然在认知上将 MVVM 概念放在一起，所以我不知道是否:

• 您必须将 INotifyPropertyChanged 放入 ViewModel 才能使 CommandSink 工作
• 这只是常态的偏差，这并不重要
• 您应该始终让模型实现 INotifyPropertyChanged，这只是一个错误，如果将其从代码示例开发为应用程序，将会得到纠正

在您从事的 MVVM 项目中，其他人有哪些经验？

Answer 1

我强烈反对模型不应实现 INotifyPropertyChanged 的概念。此界面不是特定于 UI 的!它只是通知一个变化。事实上，WPF 大量使用它来识别更改，但这并不意味着它是一个 UI 界面。我会将其与以下评论进行比较:“轮胎是汽车配件”。当然可以，但自行车、公共(public)汽车等也使用它。 总而言之，不要把那个界面当成 UI 的东西。

话虽如此，但这并不一定意味着我认为模型应该提供通知。 事实上，根据经验，模型不应实现此接口(interface)，除非有必要。在大多数情况下，没有服务器数据被推送到客户端应用程序，模型可能是陈旧的。但是如果听金融市场数据，那么我不明白为什么模型不能实现接口(interface)。例如，如果我有非 UI 逻辑，例如当它收到给定值的出价或要价时发出警报(例如通过电子邮件)或下订单的服务怎么办？这可能是一个干净的解决方案。

然而，实现目标的方式多种多样，但我始终主张简化并避免冗余。

什么更好？在 View 模型上定义集合事件或属性更改并将其传播到模型或让 View 从本质上更新模型(通过 View 模型)？

底线是，每当您看到有人声称“您不能做这个或那个”时，这表明他们不知道自己在说什么。

这真的取决于你的情况，事实上 MVVM 是一个有很多问题的框架，我还没有看到 MVVM 的普遍实现。

我希望我有更多时间来解释 MVVM 的多种风格和一些常见问题的解决方案 - 主要由其他开发人员提供，但我想我将不得不改天再做。